<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-clue-data-model-schema SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-clue-data-model-schema-17.xml">
<!ENTITY I-D.ietf-clue-framework SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-clue-framework-25.xml">
<!ENTITY I-D.ietf-mmusic-sdp-bundle-negotiation SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mmusic-sdp-bundle-negotiation-36.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3711 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY RFC5763 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml">
<!ENTITY RFC5764 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml">
<!ENTITY RFC6347 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC6904 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6904.xml">
<!ENTITY RFC7941 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7941.xml">
<!ENTITY I-D.ietf-avtcore-rtp-multi-stream SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-avtcore-rtp-multi-stream-11.xml">
<!ENTITY I-D.ietf-clue-signaling SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-clue-signaling-10.xml">
<!ENTITY RFC3264 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY RFC3550 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC3556 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3556.xml">
<!ENTITY RFC4566 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY RFC4575 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4575.xml">
<!ENTITY RFC4585 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY RFC4796 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4796.xml">
<!ENTITY RFC5124 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml">
<!ENTITY RFC5285 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5285.xml">
<!ENTITY RFC5506 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5506.xml">
<!ENTITY RFC6562 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6562.xml">
<!ENTITY RFC7022 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7022.xml">
<!ENTITY RFC7201 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7201.xml">
<!ENTITY RFC7202 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7202.xml">
<!ENTITY RFC7205 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7205.xml">
<!ENTITY RFC7667 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7667.xml">
]> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-clue-rtp-mapping-14.txt"
number="8849" docName="draft-ietf-clue-rtp-mapping-14" category="std" ipr="trust200902"> ipr="trust200902"
obsoletes="" updates="" consensus="true" xml:lang="en" symRefs="true" sortRefs="true"
tocInclude="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.39.0 -->
  <!-- Generated by id2xml 1.5.0 on 2020-02-06T00:30:19Z -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc text-list-symbols="o*+-"?>
	<?rfc toc="yes"?>
<front>

<!--[rfced] Note that the title of the document has been updated as
follows. The Abbreviation has been expanded per Section 3.6 of
RFC 7322 (“RFC Style Guide”). Please review.

Original:
Mapping RTP streams to CLUE Media Captures

Updated:
Mapping RTP Streams to Controlling Multiple Streams
for Telepresence (CLUE) Media Captures
-->
    <title abbrev="RTP mapping Mapping to CLUE">Mapping RTP streams Streams to CLUE Controlling Multiple Streams for Telepresence (CLUE) Media Captures</title>
    <seriesInfo name="RFC" value="8849"/>
    <author initials="R." surname="Even" fullname="Roni Even">
      <organization>Huawei Technologies</organization>
	<address><postal><street>Tel Aviv</street>
	<street>Israel</street>
      <address>
        <postal>
          <street/>
          <city>Tel Aviv</city>
          <code/>
          <country>Israel</country>
        </postal>
        <email>roni.even@huawei.com</email>
      </address>
    </author>

    <author initials="J." surname="Lennox" fullname="Jonathan Lennox">
      <organization abbrev="Vidyo">Vidyo, Inc.</organization>
	<address><postal><street>433
      <address>
        <postal>
          <street>433 Hackensack Avenue</street>
          <street>Seventh Floor</street>
	<street>Hackensack, NJ  07601</street>
	<street>US</street>
          <city>Hackensack</city>
          <region>NJ</region>
          <code>07601</code>
          <country>United States of America</country>
        </postal>
        <email>jonathan@vidyo.com</email>
      </address>
    </author>
    <date year="2017" month="February" day="27"/>
	<abstract><t> year="2020" month="July"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

    <abstract>
      <t>
   This document describes how the Real Time transport Real-time Transport Protocol (RTP) is used
   in the context of the CLUE protocol (ControLling mUltiple
   streams Controlling Multiple Streams for tElepresence). Telepresence (CLUE)
   protocol.  It also describes the mechanisms and recommended practice for
   mapping RTP media streams streams, as defined in the Session Description Protocol (SDP)
   (SDP), to CLUE Media Captures and defines a new RTP header extension
   (CaptureId).</t>
    </abstract>
  </front>
  <middle>

    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   Telepresence systems can send and receive multiple media streams.
   The CLUE framework Framework <xref target="I-D.ietf-clue-framework"/> target="RFC8845" format="default"/> defines Media Captures
   (MC)
   (MCs) as a source of Media, from one or more Capture Devices.  A Media
   Capture may also be constructed from other Media streams.  A middle
   box middlebox
   can express conceptual Media Captures that it constructs from
   Media streams it receives.  A Multiple Content Capture (MCC) is a
   special Media Capture composed of multiple Media Captures.</t>

	<t><list style="hanging" hangIndent="47"><t hangText="SIP

      <t>SIP Offer/Answer [RFC3264] <xref target="RFC3264" format="default"/> uses SDP [RFC4566]">
      <xref target="RFC4566" format="default"/> to describe the
	<vspace blankLines="0"/>
	RTP<xref target="RFC3550"/> RTP media streams.
	streams <xref target="RFC3550" format="default"/>.  Each RTP stream
        has a unique Synchronization Source (SSRC)
	within its RTP session.  The content of the RTP stream is created by
	an encoder in the endpoint.  This may be an original content from a
	camera or a content created by an intermediary device like an MCU (Multipoint a Multipoint Control Unit).
	</t>

	</list>
	</t> Unit (MCU).</t>
      <t>
   This document makes recommendations for the CLUE architecture about
   how RTP and RTCP RTP Control Protocol (RTCP) streams should be encoded and transmitted, transmitted and how
   their relation to CLUE Media Captures should be communicated.  The
   proposed solution supports multiple RTP topologies <xref target="RFC7667"/>.</t> target="RFC7667" format="default"/>.</t>
      <t>
   With regards to the media (audio, video video, and timed text), systems that
   support CLUE use RTP for the media, SDP for codec and media transport
   negotiation (CLUE individual encodings) encodings), and the CLUE protocol for
   Media Capture description and selection.  In order to associate the
   media in the different protocols protocols, there are three mapping mappings that need to
   be specified:</t>

	<t><list style="numbers"><t>CLUE specified:

</t>
      <ol spacing="normal" type="1">
        <li>CLUE individual encodings to SDP</t>

	<t>RTP SDP</li>
        <li>RTP streams to SDP (this is not a CLUE specific mapping)</t>

	<t>RTP CLUE-specific mapping)</li>
        <li>RTP streams to MC to map the received RTP steam stream to the current MC
in the MCC.</t>

	</list>
	</t> MCC.</li>
      </ol>
    </section>

    <section title="Terminology" anchor="sect-2"><t> anchor="sect-2" numbered="true" toc="default">
      <name>Terminology</name>
<!--[SG] Note: I edited this text to use the current keyword paragraph and
include the clue-specific text they had in the original.  Please review.
Maybe AQ -->
      <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in RFC2119<xref BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.  These key words indicate requirement levels for RTP
    processing in compliant CLUE
   implementations.</t> implementations.
</t>

      <t>
   The definitions
   Definitions from the CLUE framework document Framework
   (see <xref target="I-D.ietf-clue-framework"/> section 3 target="RFC8845" sectionFormat="of" section="3" />) are used by this document as
   well.</t>
    </section>

    <section title="RTP topologies anchor="sect-3" numbered="true" toc="default">
      <name>RTP Topologies for CLUE" anchor="sect-3"><t> CLUE</name>
      <t>
   The typical RTP topologies used by CLUE Telepresence telepresence systems specify
   different behaviors for RTP and RTCP distribution.  A number of RTP
   topologies are described in <xref target="RFC7667"/>. target="RFC7667" format="default"/>.  For CLUE telepresence, the
   relevant topologies include Point-to-Point, as well as Media-Mixing
   mixers, Media- Switching mixers,
   Mixers, Media-Switching Mixers, and Selective Forwarding Middleboxs.</t> Middleboxes.</t>
      <t>
   In the Point-to-Point topology, one peer communicates directly with a
   single peer over unicast.  There can be one or more RTP sessions,
   each sent on a separate 5-tuple, and having that have a separate SSRC space,
   with each RTP session carrying multiple RTP streams identified by
   their SSRC.  All SSRCs are recognized by the peers based on the
   information in the RTCP Source description (SDES) report that
   includes the CNAME Canonical Name (CNAME) and SSRC of the sent RTP streams.  There are
   different Point-to-Point use cases as specified in the CLUE use case
   <xref target="RFC7205"/>. target="RFC7205" format="default"/>.  In some cases, a CLUE session which, that, at a high-level, high level, is
   point-to-point may nonetheless have an RTP stream which that is best
   described by one of the mixer topologies.  For example, a CLUE
   endpoint can produce composite or switched captures for use by a
   receiving system with fewer displays than the sender has cameras.
   The Media Capture may be described using an MCC.</t>
      <t>
   For the Media Mixer media mixer topology <xref target="RFC7667"/>, target="RFC7667" format="default"/>, the peers communicate only
   with the mixer.  The mixer provides mixed or composited media
   streams, using its own SSRC for the sent streams.  If needed by the CLUE
   endpoint, the conference roster information including conference
   participants, endpoints, media media, and media-id (SSRC) can be determined
   using the conference event package <xref target="RFC4575"/> target="RFC4575" format="default"/> element.</t>
      <t>
   Media-switching mixers
   Media-Switching Mixers and Selective Forwarding Middleboxes behave as
   described in <xref target="RFC7667"/></t> target="RFC7667" format="default"/>.</t>
    </section>

    <section title="Mapping anchor="sect-4" numbered="true" toc="default">
      <name>Mapping CLUE Capture Encodings to RTP streams" anchor="sect-4"><t> Streams</name>
      <t>
   The different topologies described in <xref target="sect-3"/> target="sect-3" format="default"/> create different SSRC
   distribution models and RTP stream multiplexing points.</t>
      <t>
   Most video conferencing systems today can separate multiple RTP
   sources by placing them into RTP sessions using the SDP description;
   the video conferencing application can also have some knowledge about
   the purpose of each RTP session.  For example, video conferencing
   applications that have a primary video source and a slides video
   source can send each media source in a separate RTP session with a
   content attribute <xref target="RFC4796"/> target="RFC4796" format="default"/>, enabling different application behavior
   for each received RTP media source.  Demultiplexing is
   straightforward because each media capture is sent as a single RTP
   stream, with each RTP stream being sent in a separate RTP session, on
   a distinct UDP 5-tuple.  This will also be true for mapping the RTP
   streams to Media Captures Encodings Capture Encodings, if each Media Capture Encodings Encoding
   uses a separate RTP session, session and the consumer can identify it based
   on the receiving RTP port.  In this case, SDP only needs to label the
   RTP session with an identifier that can be used to identify the Media
   Capture in the CLUE description.  The SDP label attribute serves as
   this identifier.</t>
      <t>
<!--[rfced] Should 'Capture Encoding' be 'Media Capture Encoding' in
the following?  If that's not the case, may we lowercase this
term?

Original:
   Each Capture Encoding MUST be sent as a separate RTP stream.

Perhaps:
A) Each Media Capture Encoding MUST be sent as a separate RTP stream.

or

B) Each capture encoding MUST be sent as a separate RTP stream.
-->
   Each Capture Encoding <bcp14>MUST</bcp14> be sent as a separate RTP stream.  CLUE
   endpoints MUST <bcp14>MUST</bcp14> support sending each such RTP stream in a separate RTP
   session signalled signaled by an SDP m= "m=" line.  They MAY <bcp14>MAY</bcp14> also support sending
   some or all of the RTP streams in a single RTP session, using the
   mechanism described in <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> target="RFC8843" format="default"/> to
   relate RTP streams to SDP m= "m=" lines.</t>
      <t>
   MCCs bring another mapping issue, in that an MCC represents multiple
   Media Captures that can be sent as part of this the MCC if configured by
   the consumer.  When receiving an RTP stream which that is mapped to the
   MCC, the consumer needs to know which original MC it is in order to
   get the MC parameters from the advertisement.  If a consumer
   requested a MCC, the original MC does not have a capture encoding, so
   it cannot be associated with an m-line "m=" line using a label as described in
   CLUE signaling
   "CLUE Signaling" <xref target="I-D.ietf-clue-signaling"/>.  This target="RFC8848" format="default"/>.  It is important, for
   example, to get correct scaling information for the original MC,
   which may be different for the various MCs that are contributing to
   the MCC.</t>
    </section>

    <section title="MCC anchor="sect-5" numbered="true" toc="default">
      <name>MCC Constituent CaptureID definition" anchor="sect-5"><t> Definition</name>
      <t>
   For a an MCC which that can represent multiple switched MCs MCs, there is a need
   to know which MC is represented in the current RTP stream at any
   given time.  This requires a mapping from the SSRC of the RTP stream
   conveying a particular MCC to the constituent MC.  In order to
   address this mapping mapping, this document defines an RTP header extension
   and SDES item that includes the captureID of the original MC,
   allowing the consumer to use the MC's original source MC's attributes like
   the spatial information.</t>

<!--[rfced] This term appears in various forms; please let us know
if/how it may be made consistent.

CaptureId (in the abstract) vs. captureID vs. CaptureID

(The last one is used consistently in RFC-to-be 8848.)
-->
      <t>
   This mapping temporarily associates the SSRC of the RTP stream
   conveying a particular MCC with the captureID of the single original
   MC that is currently switched into the MCC.  This mapping cannot be
   used for the a composed case where more than one original MC is
   composed into the MCC simultaneously.</t>
      <t>
   If there is only one MC in the MCC MCC, then the media provider MUST <bcp14>MUST</bcp14> send
   the captureID of the current constituent MC in the RTP Header
   Extension and as a an RTCP CaptureID SDES item.  When the media provider
   switches the MC it sends within an MCC, it MUST <bcp14>MUST</bcp14> send the captureID
   value for the MC that just switched into the MCC in an RTP Header
   Extension and as a an RTCP CaptureID SDES item as specified in <xref target="RFC7941"/></t> target="RFC7941" format="default"/>.</t>
      <t>
   If there is more than one MC composed into the MCC MCC, then the media
   provider MUST NOT <bcp14>MUST NOT</bcp14> send any of the MCs' captureIDs using this
   mechanism.  However, if an MCC is sending contributing source Contributing Source (CSRC)
   information in the RTP header for a composed capture, it MAY <bcp14>MAY</bcp14> send the
   captureID values in the RTCP SDES packets giving source information
   for the SSRC values sent as contributing sources (CSRCs).</t> CSRCs.</t>
      <t>
   If the media provider sends the captureID of a single MC switched
   into an MCC, then later sends one composed stream of multiple MCs in
   the same MCC, it MUST <bcp14>MUST</bcp14> send the special value "-", a single dash single-dash
   character, as the captureID RTP Header Extension and RTCP CaptureID
   SDES item.  The single dash single-dash character indicates there is no
   applicable value for the MCC constituent CaptureID.  The media
   consumer interprets this as meaning that any previous CaptureID value
   associated with this SSRC no longer applies. As
   <xref target="I-D.ietf-clue-data-model-schema"/> target="RFC8846" format="default"/> defines the captureID syntax as
   "xs:ID", the single dash single-dash character is not a legal captureID value, so
   there is no possibility of confusing it with an actual captureID.</t>

      <section title="RTCP anchor="sect-5.1" numbered="true" toc="default">
        <name>RTCP CaptureID SDES Item" anchor="sect-5.1"><t><list style="hanging" hangIndent="-1"><t hangText="This Item</name>
        <t>This document specifies a new RTCP SDES item.">
	<vspace blankLines="0"/>
	</t>

	</list>
	</t>

	<figure><artwork><![CDATA[ item.</t>
        <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   CaptId=TBA   CaptId=14   |     length    | CaptureID                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ....        |
+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	<t>
   Note to the RFC Editor: Please replace TBA with the value assigned by
   IANA.</t>
        <t>
   This CaptureID is a variable-length UTF-8 string corresponding either to either
   a CaptureID negotiated in the CLUE protocol, protocol or the single
   character "-".</t>
        <t>
   This SDES item MUST <bcp14>MUST</bcp14> be sent in an SDES packet within a compound RTCP
   packet unless support for Reduced-size Reduced-Size RTCP has been negotiated as
   specified in RFC 5506 <xref target="RFC5506"/>, target="RFC5506" format="default"/>, in which case it can be sent as an
   SDES packet in a non-compound RTCP packet.</t>
      </section>

      <section title="RTP anchor="sect-5.2" numbered="true" toc="default">
        <name>RTP Header Extension" anchor="sect-5.2"><t> Extension</name>
        <t>

<!-- [rfced] RFC 5285 has been obsoleted by RFC 8285. We have updated
this reference as follows. Please let us know of any objections.

Original:
   The CaptureID is also carried in an RTP header extension [RFC5285],
   using the mechanism defined in [RFC7941].

Current:
   The CaptureID is also carried in an RTP header extension [RFC8285],
   using the mechanism defined in [RFC7941].
-->

   The CaptureID is also carried in an RTP header extension <xref target="RFC5285"/>, target="RFC8285" format="default"/>,
   using the mechanism defined in <xref target="RFC7941"/>.</t> target="RFC7941" format="default"/>.</t>
        <t>
   Support is negotiated within SDP using the URN "urn:ietf:params:rtp-hdrext:sdes:CaptureID".</t>
        <t>
   The CaptureID is sent in a an RTP Header Extension because for switched
   captures, receivers need to know which original MC corresponds to the
   media being sent for an MCC, in order to correctly apply geometric
   adjustments to the received media.</t>
        <t>
   As discussed in <xref target="RFC7941"/>, target="RFC7941" format="default"/>, there is no need to send the CaptId Header
   Extension with all RTP packets.  Senders MAY <bcp14>MAY</bcp14> choose to send it only
   when a new MC is sent.  If such a mode is being used, the header
   extension SHOULD <bcp14>SHOULD</bcp14> be sent in the first few RTP packets to reduce the
   risk of losing it due to packet loss.  See <xref target="RFC7941"/> target="RFC7941" format="default"/> for more
   discussion of this.</t> further discussion.</t>
      </section>

    </section>
    <section title="Examples" anchor="sect-6"><t> anchor="sect-6" numbered="true" toc="default">
      <name>Examples</name>
      <t>
   In this partial advertisement advertisement, the Media Provider advertises a
   composed capture VC7 made of a big picture representing the current
   speaker (VC3) and two picture-in-picture boxes representing the
   previous speakers (the previous one -VC5- -- VC5 -- and the oldest one -VC6).</t>

	<figure><artwork><![CDATA[ -- VC6).</t>

<!--[rfced] In Section 6, the partial advertisment example contains
one line that is longer than the 69-character limit.  We
inserted a line break to fix this issue; please review and
let us know if this is agreeable or if you prefer otherwise.
-->
<sourcecode type="xml"><![CDATA[
<ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/
   XMLSchema-instance"
     xsi:type="ns2:videoCaptureType" captureID="VC7"
       mediaType="video">
         <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
         <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
         <ns2:content>
               <ns2:captureIDREF>VC3</ns2:captureIDREF>
               <ns2:captureIDREF>VC5</ns2:captureIDREF>
               <ns2:captureIDREF>VC6</ns2:captureIDREF>
         </ns2:content>
                 <ns2:maxCaptures>3</ns2:maxCaptures>
           <ns2:allowSubsetChoice>false</ns2:allowSubsetChoice>
         <ns2:description lang="en">big picture of the current
           speaker pips about previous speakers</ns2:description>
           <ns2:priority>1</ns2:priority>
           <ns2:lang>it</ns2:lang>
           <ns2:mobility>static</ns2:mobility>
           <ns2:view>individual</ns2:view>
       </ns2:mediaCapture>
]]></artwork>
	</figure>
]]></sourcecode>
      <t>
   In this case case, the media provider will send capture IDs VC3, VC5 VC5, or VC6
   as an RTP header extension and RTCP SDES message for the RTP stream
   associated with the MC.</t>
      <t>
   Note that this is part of the full advertisement message example from
   the CLUE data model<xref target="I-D.ietf-clue-data-model-schema"/> model example <xref target="RFC8846" format="default"/> and is not a
   valid xml XML document.</t>
    </section>

    <section title="Communication Security" anchor="sect-7"><t> anchor="sect-7" numbered="true" toc="default">
      <name>Communication Security</name>
      <t>
   CLUE endpoints MUST <bcp14>MUST</bcp14> support RTP/SAVPF profile profiles and SRTP the Secure Real-time Transport Protocol (SRTP) <xref target="RFC3711"/>. target="RFC3711" format="default"/>.
   CLUE endpoints MUST <bcp14>MUST</bcp14> support DTLS <xref target="RFC6347"/> target="RFC6347" format="default"/> and DTLS-SRTP <xref target="RFC5763"/> target="RFC5763" format="default"/>
        <xref target="RFC5764"/> target="RFC5764" format="default"/> for SRTP keying.</t>
      <t>
   All media channels SHOULD <bcp14>SHOULD</bcp14> be secure via SRTP and the RTP/SAVPF
   profile unless the RTP media and its associated RTCP are secure by
   other means (see <xref target="RFC7201"/> target="RFC7201" format="default"/> and <xref target="RFC7202"/>).</t> target="RFC7202" format="default"/>).</t>
      <t>

<!--[rfced] Please clarify this sentence. Is it correct that all CLUE
implementations MUST implement DTLS 1.0 with the cipher suite "and" with
the P-256 curve? Please review the suggested text.

Original:
   All CLUE implementations MUST implement DTLS 1.0, with the cipher
   suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve
   [FIPS186].

Perhaps:
   All CLUE implementations MUST implement DTLS 1.0 with the
   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite and with
   the P-256 curve [FIPS186].
-->
   All CLUE implementations <bcp14>MUST</bcp14> implement DTLS 1.0, with the
   cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the P-256 curve
   <xref target="FIPS186"/>. target="FIPS186" format="default"/>.

<!--[rfced] Please confirm if the period in 'SRTP.Encrypted' is
intentional as we don't see this specific term in RFC 6904 or in
any other RFCs. Also, we deleted "MUST be supported" at the end
of the sentence since it was already stated; please review and
let us know of any objections.

Original:
   The DTLS-SRTP protection profile
   SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.Encrypted SRTP
   Header extensions <xref target="RFC6904"/> [RFC6904] MUST be supported.</t> supported.

Perhaps:
   The DTLS-SRTP protection profile, SRTP_AES128_CM_HMAC_SHA1_80,
   MUST be supported for SRTP-encrypted SRTP
   Header extensions [RFC6904].
-->
   The DTLS-SRTP protection profile
   SRTP_AES128_CM_HMAC_SHA1_80 <bcp14>MUST</bcp14> be supported for SRTP.Encrypted SRTP
   Header extensions <xref target="RFC6904" format="default"/>.</t>
      <t>
   Implementations SHOULD <bcp14>SHOULD</bcp14> implement DTLS 1.2 with the
   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
   Implementations MUST <bcp14>MUST</bcp14> favor cipher suites which that support PFS Perfect Forward Secrecy (PFS) over non-
   PFS cipher suites and SHOULD <bcp14>SHOULD</bcp14> favor AEAD Authenticated Encryption with Associated Data (AEAD) over non-AEAD cipher suites.</t>
      <t>
   NULL Protection profiles MUST NOT <bcp14>MUST NOT</bcp14> be used for RTP or RTCP.</t>
      <t>
   CLUE endpoint MUST endpoints <bcp14>MUST</bcp14> generate short-term persistent RTCP CNAMES, CNAMEs, as

   specified in <xref target="RFC7022"/>, target="RFC7022" format="default"/>, and thus can't be used for long term long-term tracking
   of the users.</t>
    </section>

    <section title="Acknowledgments" anchor="sect-8"><t>
   The authors would like to thanks Allyn Romanow and Paul Witty for
   contributing text to this work.  Magnus Westerlund helped drafting
   the security section.</t>

	</section>

	<section title="IANA Considerations" anchor="sect-9"><t> anchor="sect-9" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   This document defines a new extension URI in the RTP "RTP SDES Compact
   Header Extensions Extensions" subregistry of the Real-Time "Real-Time Transport Protocol
   (RTP) Parameters Parameters" registry, according to the following data:</t>

	<t><list style="hanging" hangIndent="3"><t>
      Extension URI: urn:ietf:params:rtp-hdrext:sdes:CaptId</t>

	</list>
	</t>

	<t><list style="hanging" hangIndent="3"><t>
      Description: CLUE CaptId</t>

	</list>
	</t>

	<t><list style="hanging" hangIndent="3"><t>
      Contact: ron.even.tlv@gmail.com</t>

	</list>
	</t>

	<t><list style="hanging" hangIndent="3"><t>
      Reference: RFC XXXX</t>

	</list>
	</t>

	<t>
   The

<dl spacing="normal">
<dt>Extension URI:</dt><dd>urn:ietf:params:rtp-hdrext:sdes:CaptId</dd>
<dt>Description:</dt><dd>CLUE CaptId</dd>
<dt>Contact:</dt><dd><t><contact fullname="Roni Even"/> &lt;ron.even.tlv@gmail.com&gt;</t></dd>
<dt>Reference:</dt><dd>RFC 8849</dd>
</dl>

<t>The IANA is requested to register has registered one new RTCP SDES items in the
"RTCP SDES Item Types" registry, as follows:</t>

	<figure><artwork><![CDATA[
   Value    Abbrev        Name                         Reference
      TBA      CCID           CLUE CaptId          [RFCXXXX]

Note to the RFC Editor: Please replace RFCXXXX with this RFC number.
]]></artwork>
	</figure>

<table anchor="table1" align="left">
<thead>
<tr>
<th>Value</th>
<th>Abbrev</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>14</td>
<td>CCID</td>
<td>CLUE CaptId</td>
<td>RFC 8849</td>
</tr>
</tbody>
</table>

    </section>
    <section title="Security Considerations" anchor="sect-10"><t> anchor="sect-10" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   The security considerations of the RTP specification, the RTP/SAVPF
   profile, and the various RTP/RTCP extensions and RTP payload formats
   that form the complete protocol suite described in this memo apply.
   It is not believed that there are any no new security considerations
   resulting from the combination of these various protocol extensions.</t>
      <t>
   The Extended "Extended Secure RTP Profile for Real-time Transport Control
   Protocol (RTCP)-Based Feedback (RTP/SAVPF)" document <xref target="RFC5124"/> (RTP/SAVPF) target="RFC5124" format="default"/> provides
   the handling of fundamental issues by offering confidentiality, integrity integrity,
   and partial source authentication.  A mandatory to implement mandatory-to-implement and use
   media security solution is created by combining this secured RTP
   profile and DTLS-SRTP keying <xref target="RFC5764"/> target="RFC5764" format="default"/> as defined in the
   communication security section of this memo <xref target="sect-7"/> (<xref target="sect-7" format="default"/>).
      </t>
      <t>
   RTCP packets convey a Canonical Name (CNAME) CNAME identifier that is used
   to associate RTP packet streams that need to be synchronised synchronized across
   related RTP sessions.  Inappropriate choice of CNAME values can be a
   privacy concern, since long-term persistent CNAME identifiers can be
   used to track users across multiple calls.  The communication
   security section of this memo <xref target="sect-7"/> (<xref target="sect-7" format="default"/>) mandates the generation of short-
   term persistent RTCP CNAMES, CNAMEs, as specified in <xref target="RFC7022"/> target="RFC7022" format="default"/>, so they can't
   be used for long term long-term tracking of the users.</t>
      <t>
   Some potential denial of service denial-of-service attacks exist if the RTCP reporting
   interval is configured to an inappropriate value.

   This could be done
   by configuring the RTCP bandwidth fraction to an excessively large or
   small value using the SDP "b=RR:" or "b=RS:" lines <xref target="RFC3556"/>, target="RFC3556" format="default"/>, or some
   similar mechanism, or by choosing an excessively large or small value
   for the RTP/AVPF minimal receiver report interval (if using SDP, this
   is the "a=rtcp-fb:... trr-int" parameter) <xref target="RFC4585"/> target="RFC4585" format="default"/>. The risks are as
   follows:</t>

	<t><list style="numbers"><t>the

      <ol spacing="normal" type="1">
        <li>The RTCP bandwidth could be configured to make the regular
       reporting interval so large that effective congestion control
       cannot be maintained, potentially leading to denial of service
       due to congestion caused by the media traffic;</t>

	<t>the traffic;</li>

        <li>The RTCP interval could be configured to a very small value,
       causing endpoints to generate high rate high-rate RTCP traffic, which potentially
       leading
       leads to denial of service due to the non-congestion controlled non-congestion-controlled
       RTCP traffic; and</t>

	<t>RTCP and</li>

        <li>RTCP parameters could be configured differently for each
       endpoint, with some of the endpoints using a large reporting
       interval and some using a smaller interval, leading to denial of
       service due to premature participant timeouts timeouts, which are due to mismatched
       timeout periods which that are based on the reporting interval (this
       is a particular concern if endpoints use a small but non-zero
       value for the RTP/AVPF minimal receiver report interval (trr-int)
       <xref target="RFC4585"/>, target="RFC4585" format="default"/>, as discussed in <xref target="I-D.ietf-avtcore-rtp-multi-stream"/>).</t>

	</list>
	</t> target="RFC8108" format="default"/>).</li>
      </ol>
      <t>
   Premature participant timeout can be avoided by using the fixed (non-
   reduced) minimum interval when calculating the participant timeout
   (<xref target="I-D.ietf-avtcore-rtp-multi-stream"/>).
   <xref target="RFC8108" format="default"/>.  To address the other
   concerns, endpoints SHOULD <bcp14>SHOULD</bcp14> ignore parameters that configure the RTCP
   reporting interval to be significantly longer than the default five
   second five-second
   interval specified in <xref target="RFC3550"/> target="RFC3550" format="default"/> (unless the media data rate is
   so low that the longer reporting interval roughly corresponds to 5%
   of the media data rate), rate) or that configure the RTCP reporting
   interval small enough that the RTCP bandwidth would exceed the media
   bandwidth.</t>
      <t>
   The guidelines in <xref target="RFC6562"/> target="RFC6562" format="default"/> apply when using variable bit rate (VBR)
   audio codecs such as Opus.</t>
      <t>
   The use of the encryption
   Encryption of the header extensions are RECOMMENDED, is <bcp14>RECOMMENDED</bcp14>,
   unless there are known reasons, like RTP middleboxes performing voice
   activity based voice-activity-based
   source selection or third party third-party monitoring that will
   greatly benefit from the information, and this has been expressed
   using API or signalling. signaling.  If further evidence are is produced to show
   that information leakage is significant from audio level indications,
   then the use of encryption needs to be mandated at that time.</t>
      <t>
   In multi-party communication scenarios using RTP Middleboxes; this middleboxes,
   the middleboxes are REQUIRED, <bcp14>REQUIRED</bcp14>, by this protocol, to not weaken the
   sessions' security.  The middlebox SHOULD <bcp14>SHOULD</bcp14> maintain the
   confidentiality, integrity maintain integrity, and perform source authentication.  The
   middlebox MAY <bcp14>MAY</bcp14> perform checks that prevents prevent any endpoint participating
   in a conference to impersonate another.  Some additional security
   considerations regarding multi-party topologies can be found in
   <xref target="RFC7667"/></t> target="RFC7667" format="default"/>.</t>
      <t>
   The CaptureID is created as part of the CLUE protocol.  The CaptId
   SDES item is used to convey the same CaptureID value in the SDES
   item.  When sending the SDES item item, the security consideration considerations
   specified in the security section of <xref target="RFC7941"/> target="RFC7941" sectionFormat="of" section="6"/> and in the
   communication security section of this memo (see <xref target="sect-7"/> target="sect-7" format="default"/>) are applicable.
   Note that since the CaptureID is carried also carried in CLUE protocol
   messages
   messages, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that this SDES item use at least similar
   protection profiles as the CLUE protocol messages carried in the CLUE
   data channel.  .</t> channel.</t>
    </section>
  </middle>
  <back>
	<references title="Normative References">

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<!--    &I-D.ietf-clue-data-model-schema;
	&I-D.ietf-clue-framework;
	&I-D.ietf-mmusic-sdp-bundle-negotiation;
	&RFC2119;
	&RFC3711;
	&RFC5763;
	&RFC5764;
	&RFC6347;
	&RFC6904;
	&RFC7941; is 8846-->
<reference anchor="RFC8846" target="http://www.rfc-editor.org/info/rfc8846">
          <front>
            <title>An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model</title>
            <author initials="R" surname="Presta" fullname="Roberta Presta">
              <organization/>
            </author>
            <author initials="S P." surname="Romano" fullname="Simon Romano">
              <organization/>
            </author>
            <date month="June" year="2020"/>
          </front>
            <seriesInfo name="DOI" value="10.17487/RFC8846"/>
            <seriesInfo name="RFC" value="8846"/>

</reference>

<!--draft-ietf-clue-framework-25 is 8845 -->
<reference anchor='RFC8845' target='https://www.rfc-editor.org/info/rfc8845'>
<front>
<title>Framework for Telepresence Multi-Streams</title>
<author initials='M' surname='Duckworth' fullname='Mark Duckworth' role='editor'>
    <organization />
</author>
<author initials='A' surname='Pepperell' fullname='Andrew Pepperell'>
    <organization />
</author>
<author initials='S' surname='Wenger' fullname='Stephan Wenger'>
    <organization />
</author>
<date month='June' year='2020' />
</front>
<seriesInfo name='RFC' value='8845' />
<seriesInfo name='DOI' value='10.17487/RFC8845' />
</reference>

<!-- draft-ietf-mmusic-sdp-bundle-negotiation (RFC 8843) -->
    <reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843">
      <front>
        <title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>
        <author initials="C" surname="Holmberg" fullname="Christer Holmberg">
          <organization/>
        </author>
        <author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
          <organization/>
        </author>
        <author initials="C" surname="Jennings" fullname="Cullen Jennings">
          <organization/>
        </author>
        <date month="April" year="2020"/>
      </front>
        <seriesInfo name="RFC" value="8843"/>
        <seriesInfo name="DOI" value="10.17487/RFC8843"/>
    </reference>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6904.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7941.xml"/>
      </references>
	<references title="Informative References">

      <references>
        <name>Informative References</name>
        <reference anchor="FIPS186"><front> anchor="FIPS186" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">
          <front>
            <title>Digital Signature Standard</title> Standard (DSS)</title>
            <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
            <author>
              <organization>National Institute of Standards and Technology</organization> Technology (NIST)</organization>
            </author>
            <date month="July" year="2013"/>
          </front>
         <refcontent>FIPS, PUB 186-4</refcontent>
        </reference>

<!-- draft-ietf-clue-signaling (RFC 8848) -->
        <reference anchor="RFC8848"
		   target="https://www.rfc-editor.org/info/rfc8848">
          <front>
            <title>Session Signaling for Controlling Multiple Streams for
	    Telepresence (CLUE)</title>
            <author initials="R" surname="Hanton" fullname="Robert Hanton">
              <organization/>
            </author>
            <author initials="P" surname="Kyzivat" fullname="Paul Kyzivat">
              <organization/>
            </author>
            <author initials="L" surname="Xiao" fullname="Lennard Xiao">
              <organization/>
            </author>
            <author initials="C" surname="Groves" fullname="Christian Groves">
              <organization/>
            </author>
           <date month="June" year="2020"/>
          </front>
             <seriesInfo name="RFC" value="8848"/>
             <seriesInfo name="FIPS" value="PUB 186-4"/> name="DOI" value="10.17487/RFC8848"/>
        </reference>
	&I-D.ietf-avtcore-rtp-multi-stream;
	&I-D.ietf-clue-signaling;
	&RFC3264;
	&RFC3550;
	&RFC3556;
	&RFC4566;
	&RFC4575;
	&RFC4585;
	&RFC4796;
	&RFC5124;
	&RFC5285;
	&RFC5506;
	&RFC6562;
	&RFC7022;
	&RFC7201;
	&RFC7202;
	&RFC7205;
	&RFC7667;

        <!--draft-ietf-avtcore-rtp-multi-stream-11 is now RFC 8101-->
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8108.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3556.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4575.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4796.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml"/>

<!--Note: RFC 5285 has been obsoleted by RFC 8285
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5285.xml"/>
-->
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5506.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6562.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7022.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7201.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7202.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7205.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7667.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8285.xml"/>

      </references>
    </references>

    <section anchor="sect-8" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
   The authors would like to thank <contact fullname="Allyn Romanow"/> and
   <contact fullname="Paul Witty"/> for
   contributing text to this work.  <contact fullname="Magnus Westerlund"/> helped draft
   the security section.</t>
    </section>

  </back>
</rfc>