One document matched: draft-westerlund-avtext-rtcp-sdes-srcname-03.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-westerlund-avtext-rtcp-sdes-srcname-03"
     ipr="trust200902">
  <front>
    <title abbrev="RTCP SDES SRCNAME">RTCP Source Description Item SRCNAME to
    Label Individual Media Sources</title>

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

      <address>
        <postal>
          <street>Farogatan 6</street>

          <city>SE-164 80 Kista</city>

          <country>Sweden</country>
        </postal>

        <phone>+46 10 714 82 87</phone>

        <email>magnus.westerlund@ericsson.com</email>
      </address>
    </author>

    <author fullname="Bo  Burman" initials="B." surname="Burman">
      <organization>Ericsson</organization>

      <address>
        <postal>
          <street>Farogatan 6</street>

          <city>SE-164 80 Kista</city>

          <country>Sweden</country>
        </postal>

        <phone>+46 10 714 13 11</phone>

        <email>bo.burman@ericsson.com</email>
      </address>
    </author>

    <date day="21" month="October" year="2013"/>

    <abstract>
      <t>This document defines a new Source Description (SDES) item called
      SRCNAME, which uniquely identifies a single media source, like a camera
      or a microphone. It also enables identification of the encoding to
      support when multiple ones are produced. That way anyone receiving the
      SDES information from a set of interlinked RTP sessions can determine
      which SSRCs are logically related to the same media source and encoding.
      In addition the new SDES item is also defined for usage with both a
      header extension and with the SDP source specific media attribute
      ("a=ssrc"). Enabling an end-point to receive the SRCNAME with the
      relevant RTP packets, as well as RTCP, or learn the source bindings
      through signalling, ahead of receiving RTP and RTCP packets.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This specification defines a new <xref
      target="RFC3550">RTP/RTCP</xref> Source Description (SDES) item called
      Source Name (SRCNAME). There exist different use cases, including
      simulcast and scalable encoding, where a sender transmit multiple RTP
      packet streams containing full or partial encodings of the same media
      source. This include multiple independent encodings, where it is
      desirable to identify the different encodings. These different packet
      streams needs to be correctly associated with media sources and
      encodings in an receiver so that they correctly use the packet
      streams.</t>

      <t>The proposed solution provides the RTP packet streams (SSRCs) with
      identities for both the media source and the specific encoding. The
      identification is done by creating a RTCP SDES item, SRCNAME, by combing
      a media source identifier and an encoding identifier separated by a full
      stop ("."). The SRCNAME can be sent periodically in RTCP SDES packets to
      enable joiners to receive the information within some time period from
      when they join. The SRCNAME is also proposed to be sent in an <xref
      target="I-D.westerlund-avtext-sdes-hdr-ext">RTP header extension for
      SDES items</xref> when it is desirable to speed up reception. For
      example by transmitting the SRCNAME in the first N RTP packets when a
      new SSRC joins an RTP session. Finally the SRCNAME can be associated
      with the SSRC in signalling, and source specific attribute is provided
      for this purpose.</t>
    </section>

    <section title="Definitions">
      <t/>

      <section title="Requirements 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 title="Terminology">
        <t>This document uses terminology defined in <xref
        target="I-D.lennox-raiarea-rtp-grouping-taxonomy">"A Taxonomy of
        Grouping Semantics and Mechanisms for Real-Time Transport Protocol
        (RTP) Sources"</xref> . In particular the following definitions:<list
            style="symbols">
            <t>Media Source</t>

            <t>Packet Stream</t>

            <t>Media Encoder</t>

            <t>Encoded Stream</t>

            <t>Dependent Stream</t>

            <t>Participant</t>

            <t>End point</t>
          </list></t>

        <t/>
      </section>
    </section>

    <section title="Motivation">
      <t>In RTP Applications where an end-point has more than one Media Source
      in a particular RTP session there can exist need to provide these media
      sources with an identifier. One reason is to be able to explicitly track
      it across any SSRC collisions with resulting SSRC changes. Another
      reason is when there exist multiple RTP Packet Streams (SSRC) associated
      with that particular media source. Especially in RTP sessions where
      multiple media sources are simultaneously transmitted. This document
      focus on the cases that results in multiple packet streams due to the
      encoding process.</t>

      <t><xref target="I-D.westerlund-avtcore-rtp-simulcast">Simulcast</xref>
      as referred to in this document is the process when communication
      participant provides a media source in multiple encodings using multiple
      media encoders with different configurations. These different encoded
      streams are then simultaneously transmitted using RTP to a receiver or a
      group of receivers. The receiver(s) need two things; First to determine
      which of the received packet streams (SSRCs) carries which media source,
      and thus determining the different media sources and secondly what
      alternative representations of each media source that exist. This can be
      accomplished using an identifier to refer to a particular encoding of a
      media source.</t>

      <t>Scalable encoding is performed by some few media encoders, with the
      prime example being <xref target="RFC6190">H.264 Scalable Video
      Codec</xref>. A scalable media codec produces one or more base layers,
      i.e. an encoded stream, and additionally one or more enhancement layers
      that are dependent on the base layer as well as selected other
      enhancement layers, these called dependent streams. The encoded and
      dependent streams can be sent using multiple RTP packet streams, called
      multi-stream transmission (MST). Thus explicit information are required
      for which media source a particular packet stream (SSRC) are containing,
      independent if it is the encoded or dependent stream. In cases where one
      uses multiple base layers, the encoding identifier can be used to
      provide RTP/RTCP level identification of the sub-groups of packet
      streams that form an independent dependency tree. The detailed
      dependency information between the encoded streams and dependent streams
      are present in meta data information objects (SEI messages) that are
      included inside the RTP payloads for <xref
      target="RFC6190">SVC</xref>.</t>

      <t>By providing media source and encoding identity information on RTP
      and RTCP level we enable or improve usages that prior has been
      impractical or sub-optimal:<list style="letters">
          <t>A multi-party sessions where the media sources dynamically join
          and leave and the central media node is source projection mixer. A
          large conference with some participant churn, in this case to rely
          solely on a signalling based solution can be problematic, as each
          signalling session between the conference and all the participants
          needs to be updated, for example using SIP, each time a participant
          joins or leaves. Thus enabling RTP/RTCP level information enables
          the joining participant's flows to be explicitly indicated as new
          media sources and alternative representations on RTP/RTCP level and
          thus correctly handled.</t>

          <t>Multicast or broadcast situations where session configuration
          information is provided ahead of the session, and the exact set of
          media sources and their identifies can't be determined and assigned
          ahead of time.</t>

          <t>To optimize the away the need for buffering or holding
          transmission in centralized mixer cases when there is some delay on
          the signalling channel. When a media source is added and the
          information is provided using signalling only, then a receiver that
          hasn't gotten the signalling yet, needs to either buffer or discard
          received media until the signalling arrives, alternatively, the
          sender needs to hold the transmission until the receiver have
          confirmed reception of signalling.</t>

          <t>By providing this information in the RTP/RTCP also enables third
          party monitoring of the RTP/RTCP streams to work better as the
          stream relations are made clear.</t>
        </list></t>

      <t>It is important to note that a particular RTP packet stream's role in
      a communication application can be quite independent to which media
      source and the particular encoding the packet stream is. Although the
      media source and encoding is sufficient information in some use cases,
      there are other cases where additional information about the current
      role of packet stream or set of streams are required. Further discussion
      of this in <xref target="sec-appid"/>.</t>

      <t>SRCNAME extends and complement the existing solutions using <xref
      target="RFC5888">SDP Media Description grouping</xref>, or <xref
      target="RFC5576">SSRC grouping within a Media Description in SDP</xref>
      or implicit or heuristic based mapping of packet streams between or
      within RTP sessions. SRCNAME enables explicit identity information at
      RTP/RTCP level in a form that are unique across the whole communication
      session, usable to create relationships on RTP/RTCP level independent if
      one or more RTP session is used, independent on how the packet streams
      are distributed over those RTP sessions and how many media sources an
      end-point have.</t>
    </section>

    <section title="Solution">
      <t>This section defines the SRCNAME identifier format and its usage as
      <xref target="RFC3550">RTCP SDES item</xref>, registers it as an SDES
      item possible to use in the <xref
      target="I-D.westerlund-avtext-sdes-hdr-ext">RTP header extension for
      SDES items</xref>, and in a <xref target="RFC5576">source specific SDP
      attribute</xref> as well.</t>

      <t/>

      <section anchor="sec-format" title="SRCNAME Format">
        <t>The SRCNAME MUST fulfill the requirements Section 6.5 in <xref
        target="RFC3550">RTP</xref> puts on SDES item values in general. These
        requirements is that it is a <xref target="RFC3629">UTF-8</xref> text
        string that have a maximum length of 255 bytes.</t>

        <t>In addition, there are format restrictions to accommodate the
        separation of the Media Source ID and the encoding ID part, as
        described by the following <xref target="RFC5234">ABNF</xref>:</t>

        <figure anchor="fig-format-abnf" title="SRCNAME Format ABNF">
          <artwork><![CDATA[
media-source-id = 1*(%x01-09 / %x0B-0C / %x0E-1F / %x21-2D / %x2F-FF)
encoding-id     = media-source-id *(%x2E media-source-id)
    ; Same as RFC 4566 "byte-string"
    ; except for space and the "." separator

srcname-content = media-source %x2E encoding-id

]]></artwork>
        </figure>

        <t>Note, the format do allow multiple "." separators, but only as part
        of the encoding ID.</t>

        <t>The media source identifier is identifying a media source (as
        defined by section 2.1.4 of <xref
        target="I-D.lennox-raiarea-rtp-grouping-taxonomy"/>). Each media
        source ID MUST be unique when combined with the CNAME. Note that if
        one intended to byte compare the combination of CNAME and
        media-source-id then one need to pad the CNAME to full 255 bytes with
        a common pattern prior to concatenation and comparison.</t>

        <t>The encoding-id identifies a particular media encoder (Section
        2.1.6 in <xref target="I-D.lennox-raiarea-rtp-grouping-taxonomy"/>)
        and its set of produced encoded or dependent streams (as defined per
        section 2.1.7 and 2.1.8 in <xref
        target="I-D.lennox-raiarea-rtp-grouping-taxonomy"/> respectively). The
        encoding-id MUST be unique in the context of the CNAME and the media
        source ID.</t>

        <t>By require uniqueness scoped by CNAME we simplify the creation of
        unique identifiers and reduce the overhead for the inclusion of
        SRCNAME. As the CNAME defines the scope of a single synchronization
        context, commonly a single host will be responsible for assigning
        media source and encoding ID to media sources and their encodings. A
        common case will be for having a single character media source ID
        followed by stop and then another single character encoding ID, e.g.
        "a.2".</t>
      </section>

      <section anchor="sec-sdes" title="SDES Item SRCNAME">
        <t>Distributing the SRCNAME using a RTCP Source Descriptions (SDES)
        item are a method that should work with all RTP topologies (assuming
        that any intermediary node is supporting this item) and existing RTP
        extensions. Thus, a new SDES item called SRCNAME are defined. That
        way, anyone receiving the SDES information from a set of interlinked
        RTP sessions or SSRCs in a single session can determine the SRCNAME
        associated with each SSRC.</t>

        <t>The SDES SRCNAME item follows the same format as the other SDES
        items defined in <xref target="RFC3550">RTP</xref>:</t>

        <figure anchor="fig-sdes-format" title="SDES SRCNAME Format">
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRCNAME=TBA1  |     length    | source name                 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

          <!--TBA1 will replaced with a number assigned by IANA. -->
        </figure>

        <t>The source name field MUST follow the <xref
        target="sec-format">above</xref> srcname-content definition.</t>

        <t>When using the SRCNAME SDES item, it is of equally importance with
        CNAME. Thus, SRCNAME is RECOMMENDED to be included in all full
        compound RTCP packets being sent. It MAY also be included in
        non-compound packets in cases where the implementation believes that
        there might be new receivers needing the information.</t>
      </section>

      <section anchor="sec-3" title="SRCNAME in SDP">
        <t><xref target="RFC5576">"Source-Specific Media Attributes in the
        Session Description Protocol (SDP)"</xref> defines a way of declaring
        attributes for SSRC in each RTP session in SDP. With a new SDES item,
        it is possible to use this framework to define how SRCNAME can also be
        provided in the SDP for each SSRC in each RTP session, thus enabling
        an end-point to declare and learn the source bindings ahead of
        receiving RTP/RTCP packets.</t>

        <t>Hence, we define a new SDP source attribute called srcname with the
        following structure:</t>

        <figure>
          <artwork><![CDATA[
a=ssrc:<ssrc-id> srcname:<srcname>
]]></artwork>
        </figure>

        <t>The srcname value MUST be identical to the SRCNAME value the media
        sender will send in the SDES SRCNAME item in the SDES RTCP
        packets.</t>

        <t>Formal <xref target="RFC5234">ABNF syntax</xref> for the "srcname"
        attribute:</t>

        <figure anchor="fig-attribute-abnf" title="SRCNAME Attribute ABNF">
          <artwork><![CDATA[
srcname-attr = "srcname:" srcname

srcname = srcname-content

attribute =/ srcname-attr
   ; The definition of "attribute" is in RFC 4566.
 ]]></artwork>
        </figure>

        <t>When used in SDP, srcname-content MUST use ISO 10646 in UTF-8
        encoding, and MUST be independent of any "a=charset".</t>
      </section>

      <section anchor="sec-header-extension"
               title="SRCNAME as RTP Header Extension">
        <t>In cases when timely deliver of the SRCNAME is required, for
        example when adding a new SSRC to an RTP session, or when new receiver
        joins a multiparty RTP session, then the SRCNAME can be included in
        the <xref target="I-D.westerlund-avtext-sdes-hdr-ext">RTP header
        extension for SDES items</xref>.</t>

        <t>The <xref target="I-D.westerlund-avtext-sdes-hdr-ext">RTP header
        extension for SDES items</xref> is functioning for any SDES item, but
        do require new SDES items to register its URN identifier. This is done
        below in the <xref target="IANA">IANA section</xref>.</t>
      </section>
    </section>

    <section title="Usage with the Offer/Answer Model">
      <t>The SDP offer/answer procedures for a=ssrc are specified in <xref
      target="RFC5576">Source-Specific Media Attributes in the Session
      Description Protocol (SDP)</xref>. The SDP offer/answer procedures for
      a=exthdr are specified in <xref target="RFC5285">A General Mechanism for
      RTP Header Extensions</xref>.</t>
    </section>

    <section title="Backward Compatibility">
      <t>Clients not supporting SRCNAME will not have the possibility to bind
      different streams to a specific media source, since they will not
      understand the SRCNAME SDES item or the RTP header extension. However,
      sending SRCNAME SDES items to a client not supporting it should not
      impose any problems since all clients should be prepared that new SDES
      items may be specified according to <xref
      target="RFC3550">RTP</xref>.</t>

      <t>According to the definition of SDP attributes in <xref
      target="RFC4566">SDP: Session Description Protocol</xref>, if an
      attribute is received that is not understood, it MUST be ignored by the
      receiver. So a receiver not supporting the a=ssrc attribute will simply
      ignore it.</t>

      <t><xref target="RFC5576">Source-Specific Media Attributes in the
      Session Description Protocol (SDP)</xref> defines rules of how new
      source attributes should be registered, which means that a receiver
      supporting RFC 5576 should be prepared that new source attributes may be
      defined. This means that a user supporting some of the source attributes
      should not have any problems when the user receives an SDP with unknown
      source attributes.</t>

      <t>RTP header extension will only be used when successfully negotiated
      in SDP, which requires support in both sender and receiver.</t>
    </section>

    <section anchor="sec-appid" title="Relation to Application Token">
      <t>There exists a proposal for an <xref
      target="I-D.even-mmusic-application-token">application token SDES
      item</xref>, who's purpose is to map SSRCs to application purposes or
      usages of the RTP packet stream. In this section the similarities and
      differences are discussed to arrive at the conclusion that for a number
      of cases both will be required to enable powerful applications.</t>

      <t>The APPID is flexible in that it allows applications or specific
      usage of RTP to define how they map the APPID tokens to particular
      purpose or usages of the streams. This is clearly intended to provide
      flexibility. For example one APPID tokens can have meanings such as
      Presentation stream, main talker, video thumbnail number 3, FEC stream
      for Audio etc. Such roles can be transient in their behavior. For
      example main talker is a role that moves around in a multiparty
      communication session based on who is the current speaker, based on
      voice activity, or a conference management interface. Thus, the APPID
      token for this role will be moved between different SSRCs. This is in
      strong contrast with SRCNAME which identifies a particular media source
      and encoding. That is not expected to move around, other than in cases
      of SSRC collisions, when they enable tracking across this event. RTP
      Mixers that perform mixes or switching between input sources, are them
      selves having conceptual media sources, which will have stable
      identities.</t>

      <t>A case that makes it clear that SRCNAME identification may benefit
      from having additional role tokens is the case of having a source
      projection mixer using simulcast from clients to mixers. From the
      perspective of a receiver, there will be multiple SSRCs visible for a
      particular media source, but the source projection mixer will select a
      sub-set of all potential streams to deliver. A given sub-setting is to
      only deliver one representation of each media source to the receiver.
      During a multiparty conference where a main speaker is shown larger at
      the receiver, and other participants are shown smaller, the mixer may
      due to congestion be forced to switch representation of the main
      speaker. If the role would be strictly associated with the encoding
      representation then main speakers video may for example be reduced in
      display size. If instead it is explicitly indicated using APPID the
      receiving application would continue to show the main speaker as a
      larger display area, despite the reduced quality to ensure the user
      continuous to understand that this is still the main talker.</t>

      <t>Where SRCNAME provides stable identification that a SSRC is
      associated with a media source and particular encoding of that media
      source, the APPID can function as a complement when needed to provide
      explicit indication of the current role and intended of application
      usage of a SSRC.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>Following the guidelines in <xref target="RFC4566">SDP</xref>, in
      <xref target="RFC5888">The Session Description Protocol (SDP) Grouping
      Framework</xref>, and in <xref target="RFC3550">RTP</xref>, the IANA is
      requested to register:</t>

      <t><list style="numbers">
          <t>A new SDES item named SRCNAME, as defined in <xref
          target="sec-sdes"/>. This item needs to be assigned an identifier
          TBA1.</t>

          <t>A new SDP source attribute named srcname, as defined in <xref
          target="sec-3"/>.</t>

          <t>New RTP header extension URN identifiers for SRCNAME, as defined
          in <xref target="sec-header-extension"/>.</t>
        </list></t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The SDES item or header extension SRCNAMEs being close to opaque
      identifiers could potentially carry additional meanings or function as
      overt channel. If the SRCNAME would be permanent between sessions, they
      have the potential for compromising the users’ privacy as they can
      be tracked between sessions. See <xref target="RFC7022">Guidelines for
      Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)</xref> for
      more discussion.</t>

      <t>A third party modification of the srcname labels either in the RTCP
      SDES items, in the SDP a=ssrc attribute, or in the RTP header extension
      can cause service disruption. By modifying labels the wrong streams
      could be associated, with potentially serious effects including media
      disruptions. If streams that are to be associated aren't associated,
      then another type of failures occur. To prevent modification, insertion
      or deletion of the srcname labels, the carrying channel needs to be
      protected by integrity protection and source authentication. For RTCP
      and RTP header extension, various solutions exist, such as <xref
      target="RFC3711">SRTP</xref>, <xref target="RFC6347">DTLS</xref>, or
      <xref target="RFC4301">IPsec</xref>. For protecting the SDP, the
      signalling channel needs to provide protection. For <xref
      target="RFC3261">SIP S/MIME</xref> are the ideal, and hop by hop <xref
      target="RFC5246">TLS</xref> provides at least some protection, although
      not perfect. For SDPs retrieved using <xref target="RFC2326">RTSP
      DESCRIBE</xref>, TLS would be the RECOMMENDED solution.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.3629'?>

      <?rfc include='reference.RFC.3550'?>

      <?rfc include='reference.RFC.5234'?>

      <?rfc include='reference.RFC.5576'?>

      <?rfc include='reference.RFC.7022'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.westerlund-avtcore-rtp-simulcast'?>

      <?rfc include='reference.I-D.lennox-raiarea-rtp-grouping-taxonomy'?>

      <?rfc include='reference.I-D.westerlund-avtext-sdes-hdr-ext'?>

      <?rfc include='reference.I-D.even-mmusic-application-token'?>

      <?rfc include='reference.RFC.4566'?>

      <?rfc include='reference.RFC.4301'?>

      <?rfc include='reference.RFC.2326'?>

      <?rfc include='reference.RFC.3261'?>

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

      <?rfc include='reference.RFC.5246'?>

      <?rfc include='reference.RFC.5285'?>

      <?rfc include='reference.RFC.5888'?>

      <?rfc include='reference.RFC.6190'?>

      <?rfc include='reference.RFC.6347'?>
    </references>
  </back>
</rfc>