rfc8849xml2.original.xml   rfc8849.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!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/bib
xml3/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.xm
l">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC3711 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3711.xml">
<!ENTITY RFC5763 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5763.xml">
<!ENTITY RFC5764 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5764.xml">
<!ENTITY RFC6347 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6347.xml">
<!ENTITY RFC6904 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6904.xml">
<!ENTITY RFC7941 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7941.xml">
<!ENTITY I-D.ietf-avtcore-rtp-multi-stream SYSTEM "https://xml2rfc.ietf.org/publ
ic/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/bib
xml3/reference.I-D.draft-ietf-clue-signaling-10.xml">
<!ENTITY RFC3264 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3264.xml">
<!ENTITY RFC3550 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3550.xml">
<!ENTITY RFC3556 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3556.xml">
<!ENTITY RFC4566 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4566.xml">
<!ENTITY RFC4575 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4575.xml">
<!ENTITY RFC4585 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4585.xml">
<!ENTITY RFC4796 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4796.xml">
<!ENTITY RFC5124 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5124.xml">
<!ENTITY RFC5285 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5285.xml">
<!ENTITY RFC5506 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5506.xml">
<!ENTITY RFC6562 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6562.xml">
<!ENTITY RFC7022 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7022.xml">
<!ENTITY RFC7201 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7201.xml">
<!ENTITY RFC7202 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7202.xml">
<!ENTITY RFC7205 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7205.xml">
<!ENTITY RFC7667 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7667.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-clue-rtp-mapping-14.txt" category
="std" ipr="trust200902">
<!-- 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>
<title abbrev="RTP mapping to CLUE">Mapping RTP streams to CLUE Media Cap
tures</title>
<author initials="R." surname="Even" fullname="Roni Even">
<organization>Huawei Technologies</organization>
<address><postal><street>Tel Aviv</street>
<street>Israel</street>
</postal>
<email>roni.even@huawei.com</email>
</address>
</author>
<author initials="J." surname="Lennox" fullname="Jonathan Lennox"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
<organization abbrev="Vidyo">Vidyo, Inc.</organization> number="8849" docName="draft-ietf-clue-rtp-mapping-14" category="std" ipr="trust
<address><postal><street>433 Hackensack Avenue</street> 200902"
<street>Seventh Floor</street> obsoletes="" updates="" consensus="true" xml:lang="en" symRefs="true" sortRefs="
<street>Hackensack, NJ 07601</street> true"
<street>US</street> tocInclude="true" version="3">
</postal> <!-- xml2rfc v2v3 conversion 2.39.0 -->
<email>jonathan@vidyo.com</email> <!-- Generated by id2xml 1.5.0 on 2020-02-06T00:30:19Z -->
</address> <front>
</author>
<date year="2017" month="February" day="27"/> <!--[rfced] Note that the title of the document has been updated as
<abstract><t> follows. The Abbreviation has been expanded per Section 3.6 of
This document describes how the Real Time transport Protocol (RTP) is RFC 7322 (“RFC Style Guide”). Please review.
used in the context of the CLUE protocol (ControLling mUltiple
streams for tElepresence). It also describes the mechanisms and
recommended practice for mapping RTP media streams defined in Session
Description Protocol (SDP) to CLUE Media Captures and defines a new
RTP header extension (CaptureId).</t>
</abstract> Original:
</front> Mapping RTP streams to CLUE Media Captures
<middle> Updated:
<section title="Introduction" anchor="sect-1"><t> Mapping RTP Streams to Controlling Multiple Streams
for Telepresence (CLUE) Media Captures
-->
<title abbrev="RTP Mapping to CLUE">Mapping RTP Streams to Controlling Multi
ple 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/>
<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 Hackensack Avenue</street>
<street>Seventh Floor</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="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 Protocol (RTP) is used
in the context of the Controlling Multiple Streams for Telepresence (CLUE)
protocol. It also describes the mechanisms and recommended practice for
mapping RTP media streams, as defined in the Session Description Protocol
(SDP), to CLUE Media Captures and defines a new RTP header extension
(CaptureId).</t>
</abstract>
</front>
<middle>
<section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name>
<t>
Telepresence systems can send and receive multiple media streams. Telepresence systems can send and receive multiple media streams.
The CLUE framework <xref target="I-D.ietf-clue-framework"/> defines Media Cap The CLUE Framework <xref target="RFC8845" format="default"/> defines Media Ca
tures ptures
(MC) as a source of Media, from one or more Capture Devices. A Media (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 Capture may also be constructed from other Media streams. A middlebox
box can express conceptual Media Captures that it constructs from can express conceptual Media Captures that it constructs from
Media streams it receives. A Multiple Content Capture (MCC) is a Media streams it receives. A Multiple Content Capture (MCC) is a
special Media Capture composed of multiple Media Captures.</t> special Media Capture composed of multiple Media Captures.</t>
<t><list style="hanging" hangIndent="47"><t hangText="SIP Offer/Answer [R <t>SIP Offer/Answer <xref target="RFC3264" format="default"/> uses SDP
FC3264] uses SDP [RFC4566]"> <xref target="RFC4566" format="default"/> to describe the RTP media
to describe the streams <xref target="RFC3550" format="default"/>. Each RTP stream
<vspace blankLines="0"/> has a unique Synchronization Source (SSRC)
RTP<xref target="RFC3550"/> media streams. Each RTP stream has a unique within its RTP session. The content of the RTP stream is created by
Synchronization Source (SSRC) within its RTP session. The content of an encoder in the endpoint. This may be an original content from a
the RTP stream is created by an encoder in the endpoint. This may be camera or a content created by an intermediary device like a Multipoint C
an original content from a camera or a content created by an ontrol Unit (MCU).</t>
intermediary device like an MCU (Multipoint Control Unit). <t>
</t>
</list>
</t>
<t>
This document makes recommendations for the CLUE architecture about This document makes recommendations for the CLUE architecture about
how RTP and RTCP streams should be encoded and transmitted, and how how RTP and RTP Control Protocol (RTCP) streams should be encoded and transmi tted and how
their relation to CLUE Media Captures should be communicated. The their relation to CLUE Media Captures should be communicated. The
proposed solution supports multiple RTP topologies <xref target="RFC7667"/>.< proposed solution supports multiple RTP topologies <xref target="RFC7667" for
/t> mat="default"/>.</t>
<t>
<t> With regards to the media (audio, video, and timed text), systems that
With regards to the media (audio, video and timed text), systems that
support CLUE use RTP for the media, SDP for codec and media transport support CLUE use RTP for the media, SDP for codec and media transport
negotiation (CLUE individual encodings) and the CLUE protocol for negotiation (CLUE individual encodings), and the CLUE protocol for
Media Capture description and selection. In order to associate the Media Capture description and selection. In order to associate the
media in the different protocols there are three mapping that need to media in the different protocols, there are three mappings that need to
be specified:</t> be specified:
<t><list style="numbers"><t>CLUE individual encodings to SDP</t>
<t>RTP streams to SDP (this is not a CLUE specific mapping)</t>
<t>RTP streams to MC to map the received RTP steam to the current MC
in the MCC.</t>
</list>
</t>
</section> </t>
<ol spacing="normal" type="1">
<li>CLUE individual encodings to SDP</li>
<li>RTP streams to SDP (this is not a CLUE-specific mapping)</li>
<li>RTP streams to MC to map the received RTP stream to the current MC
in the MCC.</li>
</ol>
</section>
<section title="Terminology" anchor="sect-2"><t> <section anchor="sect-2" numbered="true" toc="default">
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Terminology</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this <!--[SG] Note: I edited this text to use the current keyword paragraph and
document are to be interpreted as described in RFC2119<xref target="RFC2119"/ include the clue-specific text they had in the original. Please review.
> and Maybe AQ -->
indicate requirement levels for RTP processing in compliant CLUE <t>
implementations.</t> The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in 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>
<t> <t>
The definitions from the CLUE framework document Definitions from the CLUE Framework
<xref target="I-D.ietf-clue-framework"/> section 3 are used by this document (see <xref target="RFC8845" sectionFormat="of" section="3" />) are used by th
as is document as
well.</t> well.</t>
</section>
</section> <section anchor="sect-3" numbered="true" toc="default">
<name>RTP Topologies for CLUE</name>
<section title="RTP topologies for CLUE" anchor="sect-3"><t> <t>
The typical RTP topologies used by CLUE Telepresence systems specify The typical RTP topologies used by CLUE telepresence systems specify
different behaviors for RTP and RTCP distribution. A number of RTP different behaviors for RTP and RTCP distribution. A number of RTP
topologies are described in <xref target="RFC7667"/>. For CLUE telepresence, the topologies are described in <xref target="RFC7667" format="default"/>. For C LUE telepresence, the
relevant topologies include Point-to-Point, as well as Media-Mixing relevant topologies include Point-to-Point, as well as Media-Mixing
mixers, Media- Switching mixers, and Selective Forwarding Middleboxs.</t> Mixers, Media-Switching Mixers, and Selective Forwarding Middleboxes.</t>
<t>
<t>
In the Point-to-Point topology, one peer communicates directly with a In the Point-to-Point topology, one peer communicates directly with a
single peer over unicast. There can be one or more RTP sessions, single peer over unicast. There can be one or more RTP sessions,
each sent on a separate 5-tuple, and having a separate SSRC space, each sent on a separate 5-tuple, that have a separate SSRC space,
with each RTP session carrying multiple RTP streams identified by with each RTP session carrying multiple RTP streams identified by
their SSRC. All SSRCs are recognized by the peers based on the their SSRC. All SSRCs are recognized by the peers based on the
information in the RTCP Source description (SDES) report that information in the RTCP Source description (SDES) report that
includes the CNAME and SSRC of the sent RTP streams. There are includes the Canonical Name (CNAME) and SSRC of the sent RTP streams. There
different Point-to-Point use cases as specified in CLUE use case are
<xref target="RFC7205"/>. In some cases, a CLUE session which, at a high-lev different Point-to-Point use cases as specified in the CLUE use case
el, is <xref target="RFC7205" format="default"/>. In some cases, a CLUE session tha
point-to-point may nonetheless have an RTP stream which is best t, at a high level, is
point-to-point may nonetheless have an RTP stream that is best
described by one of the mixer topologies. For example, a CLUE described by one of the mixer topologies. For example, a CLUE
endpoint can produce composite or switched captures for use by a endpoint can produce composite or switched captures for use by a
receiving system with fewer displays than the sender has cameras. receiving system with fewer displays than the sender has cameras.
The Media Capture may be described using an MCC.</t> The Media Capture may be described using an MCC.</t>
<t>
<t> For the media mixer topology <xref target="RFC7667" format="default"/>, the p
For the Media Mixer topology <xref target="RFC7667"/>, the peers communicate eers communicate only
only
with the mixer. The mixer provides mixed or composited media with the mixer. The mixer provides mixed or composited media
streams, using its own SSRC for the sent streams. If needed by CLUE streams, using its own SSRC for the sent streams. If needed by the CLUE
endpoint, the conference roster information including conference endpoint, the conference roster information including conference
participants, endpoints, media and media-id (SSRC) can be determined participants, endpoints, media, and media-id (SSRC) can be determined
using the conference event package <xref target="RFC4575"/> element.</t> using the conference event package <xref target="RFC4575" format="default"/>
element.</t>
<t> <t>
Media-switching mixers and Selective Forwarding Middleboxes behave as Media-Switching Mixers and Selective Forwarding Middleboxes behave as
described in <xref target="RFC7667"/></t> described in <xref target="RFC7667" format="default"/>.</t>
</section>
</section>
<section title="Mapping CLUE Capture Encodings to RTP streams" anchor="se <section anchor="sect-4" numbered="true" toc="default">
ct-4"><t> <name>Mapping CLUE Capture Encodings to RTP Streams</name>
The different topologies described in <xref target="sect-3"/> create differen <t>
t SSRC The different topologies described in <xref target="sect-3" format="default"/
> create different SSRC
distribution models and RTP stream multiplexing points.</t> distribution models and RTP stream multiplexing points.</t>
<t>
<t>
Most video conferencing systems today can separate multiple RTP Most video conferencing systems today can separate multiple RTP
sources by placing them into RTP sessions using the SDP description; sources by placing them into RTP sessions using the SDP description;
the video conferencing application can also have some knowledge about the video conferencing application can also have some knowledge about
the purpose of each RTP session. For example, video conferencing the purpose of each RTP session. For example, video conferencing
applications that have a primary video source and a slides video applications that have a primary video source and a slides video
source can send each media source in a separate RTP session with a source can send each media source in a separate RTP session with a
content attribute <xref target="RFC4796"/> enabling different application beh avior content attribute <xref target="RFC4796" format="default"/>, enabling differe nt application behavior
for each received RTP media source. Demultiplexing is for each received RTP media source. Demultiplexing is
straightforward because each media capture is sent as a single RTP straightforward because each media capture is sent as a single RTP
stream, with each RTP stream being sent in a separate RTP session, on 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 a distinct UDP 5-tuple. This will also be true for mapping the RTP
streams to Media Captures Encodings if each Media Capture Encodings streams to Media Capture Encodings, if each Media Capture Encoding
uses a separate RTP session, and the consumer can identify it based uses a separate RTP session and the consumer can identify it based
on the receiving RTP port. In this case, SDP only needs to label the 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 RTP session with an identifier that can be used to identify the Media
Capture in the CLUE description. The SDP label attribute serves as Capture in the CLUE description. The SDP label attribute serves as
this identifier.</t> 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?
<t> Original:
Each Capture Encoding MUST be sent as a separate RTP stream. CLUE Each Capture Encoding MUST be sent as a separate RTP stream.
endpoints MUST support sending each such RTP stream in a separate RTP
session signalled by an SDP m= line. They MAY 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"/
> to
relate RTP streams to SDP m= lines.</t>
<t> 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 <bcp14>MUST</bcp14> support sending each such RTP stream in a separ
ate RTP
session signaled by an SDP "m=" line. They <bcp14>MAY</bcp14> also support s
ending
some or all of the RTP streams in a single RTP session, using the
mechanism described in <xref target="RFC8843" format="default"/> to
relate RTP streams to SDP "m=" lines.</t>
<t>
MCCs bring another mapping issue, in that an MCC represents multiple MCCs bring another mapping issue, in that an MCC represents multiple
Media Captures that can be sent as part of this MCC if configured by Media Captures that can be sent as part of the MCC if configured by
the consumer. When receiving an RTP stream which is mapped to the the consumer. When receiving an RTP stream that is mapped to the
MCC, the consumer needs to know which original MC it is in order to MCC, the consumer needs to know which original MC it is in order to
get the MC parameters from the advertisement. If a consumer get the MC parameters from the advertisement. If a consumer
requested a MCC, the original MC does not have a capture encoding, so requested a MCC, the original MC does not have a capture encoding, so
it cannot be associated with an m-line using a label as described in it cannot be associated with an "m=" line using a label as described in
CLUE signaling <xref target="I-D.ietf-clue-signaling"/>. This is important, "CLUE Signaling" <xref target="RFC8848" format="default"/>. It is important,
for for
example, to get correct scaling information for the original MC, example, to get correct scaling information for the original MC,
which may be different for the various MCs that are contributing to which may be different for the various MCs that are contributing to
the MCC.</t> the MCC.</t>
</section>
</section> <section anchor="sect-5" numbered="true" toc="default">
<name>MCC Constituent CaptureID Definition</name>
<section title="MCC Constituent CaptureID definition" anchor="sect-5"><t> <t>
For a MCC which can represent multiple switched MCs there is a need For an MCC that can represent multiple switched MCs, there is a need
to know which MC is represented in the current RTP stream at any 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 given time. This requires a mapping from the SSRC of the RTP stream
conveying a particular MCC to the constituent MC. In order to conveying a particular MCC to the constituent MC. In order to
address this mapping this document defines an RTP header extension address this mapping, this document defines an RTP header extension
and SDES item that includes the captureID of the original MC, and SDES item that includes the captureID of the original MC,
allowing the consumer to use the original source MC's attributes like allowing the consumer to use the MC's original source attributes like
the spatial information.</t> the spatial information.</t>
<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 This mapping temporarily associates the SSRC of the RTP stream
conveying a particular MCC with the captureID of the single original conveying a particular MCC with the captureID of the single original
MC that is currently switched into the MCC. This mapping cannot be MC that is currently switched into the MCC. This mapping cannot be
used for the composed case where more than one original MC is used for a composed case where more than one original MC is
composed into the MCC simultaneously.</t> composed into the MCC simultaneously.</t>
<t>
<t> If there is only one MC in the MCC, then the media provider <bcp14>MUST</bcp1
If there is only one MC in the MCC then the media provider MUST send 4> send
the captureID of the current constituent MC in the RTP Header the captureID of the current constituent MC in the RTP Header
Extension and as a RTCP CaptureID SDES item. When the media provider Extension and as an RTCP CaptureID SDES item. When the media provider
switches the MC it sends within an MCC, it MUST send the captureID switches the MC it sends within an MCC, it <bcp14>MUST</bcp14> send the captu
value for the MC just switched into the MCC in an RTP Header reID
Extension and as a RTCP CaptureID SDES item as specified in <xref target="RFC value for the MC that just switched into the MCC in an RTP Header
7941"/></t> Extension and as an RTCP CaptureID SDES item as specified in <xref target="RF
C7941" format="default"/>.</t>
<t> <t>
If there is more than one MC composed into the MCC then the media If there is more than one MC composed into the MCC, then the media
provider MUST NOT send any of the MCs' captureIDs using this provider <bcp14>MUST NOT</bcp14> send any of the MCs' captureIDs using this
mechanism. However, if an MCC is sending contributing source (CSRC) mechanism. However, if an MCC is sending Contributing Source (CSRC)
information in the RTP header for a composed capture, it MAY send the information in the RTP header for a composed capture, it <bcp14>MAY</bcp14> s
end the
captureID values in the RTCP SDES packets giving source information captureID values in the RTCP SDES packets giving source information
for the SSRC values sent as contributing sources (CSRCs).</t> for the SSRC values sent as CSRCs.</t>
<t>
<t>
If the media provider sends the captureID of a single MC switched 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 into an MCC, then later sends one composed stream of multiple MCs in
the same MCC, it MUST send the special value "-", a single dash the same MCC, it <bcp14>MUST</bcp14> send the special value "-", a single-das h
character, as the captureID RTP Header Extension and RTCP CaptureID character, as the captureID RTP Header Extension and RTCP CaptureID
SDES item. The single dash character indicates there is no SDES item. The single-dash character indicates there is no
applicable value for the MCC constituent CaptureID. The media applicable value for the MCC constituent CaptureID. The media
consumer interprets this as meaning that any previous CaptureID value consumer interprets this as meaning that any previous CaptureID value
associated with this SSRC no longer applies. As associated with this SSRC no longer applies. As
<xref target="I-D.ietf-clue-data-model-schema"/> defines the captureID syntax <xref target="RFC8846" format="default"/> defines the captureID syntax as
as "xs:ID", the single-dash character is not a legal captureID value, so
"xs:ID", the single dash character is not a legal captureID value, so
there is no possibility of confusing it with an actual captureID.</t> there is no possibility of confusing it with an actual captureID.</t>
<section title="RTCP CaptureID SDES Item" anchor="sect-5.1"><t><list styl <section anchor="sect-5.1" numbered="true" toc="default">
e="hanging" hangIndent="-1"><t hangText="This document specifies a new RTCP SDES <name>RTCP CaptureID SDES Item</name>
item."> <t>This document specifies a new RTCP SDES item.</t>
<vspace blankLines="0"/> <artwork name="" type="" align="left" alt=""><![CDATA[
</t>
</list>
</t>
<figure><artwork><![CDATA[
0 1 2 3 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 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 | length | CaptureID | | CaptId=14 | length | CaptureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... | | .... |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <t>
<t> This CaptureID is a variable-length UTF-8 string corresponding to either
Note to the RFC Editor: Please replace TBA with the value assigned by a CaptureID negotiated in the CLUE protocol or the single
IANA.</t>
<t>
This CaptureID is a variable-length UTF-8 string corresponding either
to a CaptureID negotiated in the CLUE protocol, or the single
character "-".</t> character "-".</t>
<t>
<t> This SDES item <bcp14>MUST</bcp14> be sent in an SDES packet within a compoun
This SDES item MUST be sent in an SDES packet within a compound RTCP d RTCP
packet unless support for Reduced-size RTCP has been negotiated as packet unless support for Reduced-Size RTCP has been negotiated as
specified in RFC 5506 <xref target="RFC5506"/>, in which case it can be sent specified in RFC 5506 <xref target="RFC5506" format="default"/>, in which cas
as an e it can be sent as an
SDES packet in a non-compound RTCP packet.</t> SDES packet in a non-compound RTCP packet.</t>
</section>
</section> <section anchor="sect-5.2" numbered="true" toc="default">
<name>RTP Header Extension</name>
<t>
<section title="RTP Header Extension" anchor="sect-5.2"><t> <!-- [rfced] RFC 5285 has been obsoleted by RFC 8285. We have updated
The CaptureID is also carried in an RTP header extension <xref target="RFC528 this reference as follows. Please let us know of any objections.
5"/>,
using the mechanism defined in <xref target="RFC7941"/>.</t>
<t> Original:
Support is negotiated within SDP using the URN "urn:ietf:params:rtp-hdrext:sd The CaptureID is also carried in an RTP header extension [RFC5285],
es:CaptureID".</t> using the mechanism defined in [RFC7941].
<t> Current:
The CaptureID is sent in a RTP Header Extension because for switched 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="RFC828
5" format="default"/>,
using the mechanism defined in <xref target="RFC7941" format="default"/>.</t>
<t>
Support is negotiated within SDP using the URN "urn:ietf:params:rtp-hdrext:sd
es:CaptureID".</t>
<t>
The CaptureID is sent in an RTP Header Extension because for switched
captures, receivers need to know which original MC corresponds to the captures, receivers need to know which original MC corresponds to the
media being sent for an MCC, in order to correctly apply geometric media being sent for an MCC, in order to correctly apply geometric
adjustments to the received media.</t> adjustments to the received media.</t>
<t>
<t> As discussed in <xref target="RFC7941" format="default"/>, there is no need t
As discussed in <xref target="RFC7941"/>, there is no need to send the CaptId o send the CaptId Header
Header Extension with all RTP packets. Senders <bcp14>MAY</bcp14> choose to send it
Extension with all RTP packets. Senders MAY choose to send it only only
when a new MC is sent. If such a mode is being used, the header when a new MC is sent. If such a mode is being used, the header
extension SHOULD be sent in the first few RTP packets to reduce the extension <bcp14>SHOULD</bcp14> be sent in the first few RTP packets to reduc
risk of losing it due to packet loss. See <xref target="RFC7941"/> for more e the
discussion of this.</t> risk of losing it due to packet loss. See <xref target="RFC7941" format="def
ault"/> for further discussion.</t>
</section> </section>
</section>
<section title="Examples" anchor="sect-6"><t> </section>
In this partial advertisement the Media Provider advertises a <section anchor="sect-6" numbered="true" toc="default">
<name>Examples</name>
<t>
In this partial advertisement, the Media Provider advertises a
composed capture VC7 made of a big picture representing the current composed capture VC7 made of a big picture representing the current
speaker (VC3) and two picture-in-picture boxes representing the speaker (VC3) and two picture-in-picture boxes representing the
previous speakers (the previous one -VC5- and the oldest one -VC6).</t> previous speakers (the previous one -- VC5 -- and the oldest one -- VC6).</t>
<figure><artwork><![CDATA[ <!--[rfced] In Section 6, the partial advertisment example contains
<ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" one line that is longer than the 69-character limit. We
xsi:type="ns2:videoCaptureType" captureID="VC7" mediaType="video"> 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"
xsi:type="ns2:videoCaptureType" captureID="VC7"
mediaType="video">
<ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF> <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
<ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable> <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
<ns2:content> <ns2:content>
<ns2:captureIDREF>VC3</ns2:captureIDREF> <ns2:captureIDREF>VC3</ns2:captureIDREF>
<ns2:captureIDREF>VC5</ns2:captureIDREF> <ns2:captureIDREF>VC5</ns2:captureIDREF>
<ns2:captureIDREF>VC6</ns2:captureIDREF> <ns2:captureIDREF>VC6</ns2:captureIDREF>
</ns2:content> </ns2:content>
<ns2:maxCaptures>3</ns2:maxCaptures> <ns2:maxCaptures>3</ns2:maxCaptures>
<ns2:allowSubsetChoice>false</ns2:allowSubsetChoice> <ns2:allowSubsetChoice>false</ns2:allowSubsetChoice>
<ns2:description lang="en">big picture of the current speaker <ns2:description lang="en">big picture of the current
pips about previous speakers</ns2:description> speaker pips about previous speakers</ns2:description>
<ns2:priority>1</ns2:priority> <ns2:priority>1</ns2:priority>
<ns2:lang>it</ns2:lang> <ns2:lang>it</ns2:lang>
<ns2:mobility>static</ns2:mobility> <ns2:mobility>static</ns2:mobility>
<ns2:view>individual</ns2:view> <ns2:view>individual</ns2:view>
</ns2:mediaCapture> </ns2:mediaCapture>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> In this case, the media provider will send capture IDs VC3, VC5, or VC6
In this case the media provider will send capture IDs VC3, VC5 or VC6
as an RTP header extension and RTCP SDES message for the RTP stream as an RTP header extension and RTCP SDES message for the RTP stream
associated with the MC.</t> associated with the MC.</t>
<t>
<t>
Note that this is part of the full advertisement message example from Note that this is part of the full advertisement message example from
CLUE data model<xref target="I-D.ietf-clue-data-model-schema"/> example and i the CLUE data model example <xref target="RFC8846" format="default"/> and is
s not a not a
valid xml document.</t> valid XML document.</t>
</section>
</section>
<section title="Communication Security" anchor="sect-7"><t>
CLUE endpoints MUST support RTP/SAVPF profile and SRTP <xref target="RFC3711"
/>.
CLUE endpoints MUST support DTLS <xref target="RFC6347"/> and DTLS-SRTP <xref
target="RFC5763"/>
<xref target="RFC5764"/> for SRTP keying.</t>
<t> <section anchor="sect-7" numbered="true" toc="default">
All media channels SHOULD be secure via SRTP and the RTP/SAVPF <name>Communication Security</name>
<t>
CLUE endpoints <bcp14>MUST</bcp14> support RTP/SAVPF profiles and the Secure
Real-time Transport Protocol (SRTP) <xref target="RFC3711" format="default"/>.
CLUE endpoints <bcp14>MUST</bcp14> support DTLS <xref target="RFC6347" format
="default"/> and DTLS-SRTP <xref target="RFC5763" format="default"/>
<xref target="RFC5764" format="default"/> for SRTP keying.</t>
<t>
All media channels <bcp14>SHOULD</bcp14> be secure via SRTP and the RTP/SAVPF
profile unless the RTP media and its associated RTCP are secure by profile unless the RTP media and its associated RTCP are secure by
other means (see <xref target="RFC7201"/> <xref target="RFC7202"/>).</t> other means (see <xref target="RFC7201" format="default"/> and <xref target="
RFC7202" format="default"/>).</t>
<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 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 suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve
<xref target="FIPS186"/>. The DTLS-SRTP protection profile [FIPS186].
SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.Encrypted SRTP
Header extensions <xref target="RFC6904"/> MUST be supported.</t>
<t>
Implementations SHOULD implement DTLS 1.2 with the
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
Implementations MUST favor cipher suites which support PFS over non-
PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites.</t>
<t>
NULL Protection profiles MUST NOT be used for RTP or RTCP.</t>
<t>
CLUE endpoint MUST generate short-term persistent RTCP CNAMES, as
specified in <xref target="RFC7022"/>, and thus can't be used for long term t
racking
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>
This document defines a new extension URI in the RTP SDES Compact
Header Extensions subregistry of the Real-Time Transport Protocol
(RTP) 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> Perhaps:
Description: CLUE CaptId</t> 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" format="default"/>.
</list> <!--[rfced] Please confirm if the period in 'SRTP.Encrypted' is
</t> 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.
<t><list style="hanging" hangIndent="3"><t> Original:
Contact: ron.even.tlv@gmail.com</t> The DTLS-SRTP protection profile
SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.Encrypted SRTP
Header extensions [RFC6904] MUST be supported.
</list> Perhaps:
</t> 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.Encrypt
ed SRTP
Header extensions <xref target="RFC6904" format="default"/>.</t>
<t>
Implementations <bcp14>SHOULD</bcp14> implement DTLS 1.2 with the
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
Implementations <bcp14>MUST</bcp14> favor cipher suites that support Perfect
Forward Secrecy (PFS) over non-
PFS cipher suites and <bcp14>SHOULD</bcp14> favor Authenticated Encryption wi
th Associated Data (AEAD) over non-AEAD cipher suites.</t>
<t>
NULL Protection profiles <bcp14>MUST NOT</bcp14> be used for RTP or RTCP.</t>
<t>
CLUE endpoints <bcp14>MUST</bcp14> generate short-term persistent RTCP CNAMEs
, as
<t><list style="hanging" hangIndent="3"><t> specified in <xref target="RFC7022" format="default"/>, and thus can't be use
Reference: RFC XXXX</t> d for long-term tracking
of the users.</t>
</section>
</list> <section anchor="sect-9" numbered="true" toc="default">
</t> <name>IANA Considerations</name>
<t>
This document defines a new extension URI in the "RTP SDES Compact
Header Extensions" subregistry of the "Real-Time Transport Protocol
(RTP) Parameters" registry, according to the following data:</t>
<t> <dl spacing="normal">
The IANA is requested to register one new RTCP SDES items in the <dt>Extension URI:</dt><dd>urn:ietf:params:rtp-hdrext:sdes:CaptId</dd>
"RTCP SDES Item Types" registry, as follows:</t> <dt>Description:</dt><dd>CLUE CaptId</dd>
<dt>Contact:</dt><dd><t><contact fullname="Roni Even"/> &lt;ron.even.tlv@gmail.c
om&gt;</t></dd>
<dt>Reference:</dt><dd>RFC 8849</dd>
</dl>
<figure><artwork><![CDATA[ <t>The IANA has registered one new RTCP SDES items in the
Value Abbrev Name Reference "RTCP SDES Item Types" registry, as follows:</t>
TBA CCID CLUE CaptId [RFCXXXX]
Note to the RFC Editor: Please replace RFCXXXX with this RFC number. <table anchor="table1" align="left">
]]></artwork> <thead>
</figure> <tr>
</section> <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 title="Security Considerations" anchor="sect-10"><t> </section>
<section anchor="sect-10" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
The security considerations of the RTP specification, the RTP/SAVPF The security considerations of the RTP specification, the RTP/SAVPF
profile, and the various RTP/RTCP extensions and RTP payload formats profile, and the various RTP/RTCP extensions and RTP payload formats
that form the complete protocol suite described in this memo apply. that form the complete protocol suite described in this memo apply.
It is not believed there are any new security considerations It is believed that there are no new security considerations
resulting from the combination of these various protocol extensions.</t> resulting from the combination of these various protocol extensions.</t>
<t>
<t> The "Extended Secure RTP Profile for Real-time Transport Control
The Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" document <xref target="RFC5124" f
Protocol (RTCP)-Based Feedback <xref target="RFC5124"/> (RTP/SAVPF) provides ormat="default"/> provides
handling of fundamental issues by offering confidentiality, integrity the handling of fundamental issues by offering confidentiality, integrity,
and partial source authentication. A mandatory to implement and use and partial source authentication. A mandatory-to-implement and use
media security solution is created by combining this secured RTP media security solution is created by combining this secured RTP
profile and DTLS-SRTP keying <xref target="RFC5764"/> as defined in the profile and DTLS-SRTP keying <xref target="RFC5764" format="default"/> as def
communication security section of this memo <xref target="sect-7"/> ined in the
</t> communication security section of this memo (<xref target="sect-7" format="de
fault"/>).
<t> </t>
RTCP packets convey a Canonical Name (CNAME) identifier that is used <t>
to associate RTP packet streams that need to be synchronised across RTCP packets convey a CNAME identifier that is used
to associate RTP packet streams that need to be synchronized across
related RTP sessions. Inappropriate choice of CNAME values can be a related RTP sessions. Inappropriate choice of CNAME values can be a
privacy concern, since long-term persistent CNAME identifiers can be privacy concern, since long-term persistent CNAME identifiers can be
used to track users across multiple calls. The communication used to track users across multiple calls. The communication
security section of this memo <xref target="sect-7"/> mandates generation of security section of this memo (<xref target="sect-7" format="default"/>) mand
short- ates the generation of short-
term persistent RTCP CNAMES, as specified in <xref target="RFC7022"/> so they term persistent RTCP CNAMEs, as specified in <xref target="RFC7022" format="d
can't efault"/>, so they can't
be used for long term tracking of the users.</t> be used for long-term tracking of the users.</t>
<t>
Some potential denial-of-service attacks exist if the RTCP reporting
interval is configured to an inappropriate value.
<t> This could be done
Some potential 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 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"/>, or some small value using the SDP "b=RR:" or "b=RS:" lines <xref target="RFC3556" for mat="default"/>, or some
similar mechanism, or by choosing an excessively large or small value similar mechanism, or by choosing an excessively large or small value
for the RTP/AVPF minimal receiver report interval (if using SDP, this for the RTP/AVPF minimal receiver report interval (if using SDP, this
is the "a=rtcp-fb:... trr-int" parameter) <xref target="RFC4585"/> The risks are as is the "a=rtcp-fb:... trr-int" parameter) <xref target="RFC4585" format="defa ult"/>. The risks are as
follows:</t> follows:</t>
<t><list style="numbers"><t>the RTCP bandwidth could be configured to mak <ol spacing="normal" type="1">
e the regular <li>The RTCP bandwidth could be configured to make the regular
reporting interval so large that effective congestion control reporting interval so large that effective congestion control
cannot be maintained, potentially leading to denial of service cannot be maintained, potentially leading to denial of service
due to congestion caused by the media traffic;</t> due to congestion caused by the media traffic;</li>
<t>the RTCP interval could be configured to a very small value, <li>The RTCP interval could be configured to a very small value,
causing endpoints to generate high rate RTCP traffic, potentially causing endpoints to generate high-rate RTCP traffic, which potentially
leading to denial of service due to the non-congestion controlled leads to denial of service due to the non-congestion-controlled
RTCP traffic; and</t> RTCP traffic; and</li>
<t>RTCP parameters could be configured differently for each <li>RTCP parameters could be configured differently for each
endpoint, with some of the endpoints using a large reporting endpoint, with some of the endpoints using a large reporting
interval and some using a smaller interval, leading to denial of interval and some using a smaller interval, leading to denial of
service due to premature participant timeouts due to mismatched service due to premature participant timeouts, which are due to mismatche
timeout periods which are based on the reporting interval (this d
timeout periods that are based on the reporting interval (this
is a particular concern if endpoints use a small but non-zero is a particular concern if endpoints use a small but non-zero
value for the RTP/AVPF minimal receiver report interval (trr-int) value for the RTP/AVPF minimal receiver report interval (trr-int)
<xref target="RFC4585"/>, as discussed in <xref target="I-D.ietf-avtcore- <xref target="RFC4585" format="default"/>, as discussed in <xref target="
rtp-multi-stream"/>).</t> RFC8108" format="default"/>).</li>
</ol>
</list> <t>
</t>
<t>
Premature participant timeout can be avoided by using the fixed (non- Premature participant timeout can be avoided by using the fixed (non-
reduced) minimum interval when calculating the participant timeout reduced) minimum interval when calculating the participant timeout
(<xref target="I-D.ietf-avtcore-rtp-multi-stream"/>). To address the other <xref target="RFC8108" format="default"/>. To address the other
concerns, endpoints SHOULD ignore parameters that configure the RTCP concerns, endpoints <bcp14>SHOULD</bcp14> ignore parameters that configure th
reporting interval to be significantly longer than the default five e RTCP
second interval specified in <xref target="RFC3550"/> (unless the media data reporting interval to be significantly longer than the default five-second
rate is interval specified in <xref target="RFC3550" format="default"/> (unless the m
edia data rate is
so low that the longer reporting interval roughly corresponds to 5% so low that the longer reporting interval roughly corresponds to 5%
of the media data rate), or that configure the RTCP reporting of the media data rate) or that configure the RTCP reporting
interval small enough that the RTCP bandwidth would exceed the media interval small enough that the RTCP bandwidth would exceed the media
bandwidth.</t> bandwidth.</t>
<t>
<t> The guidelines in <xref target="RFC6562" format="default"/> apply when using
The guidelines in <xref target="RFC6562"/> apply when using variable bit rate variable bit rate (VBR)
(VBR)
audio codecs such as Opus.</t> audio codecs such as Opus.</t>
<t>
<t> Encryption of the header extensions is <bcp14>RECOMMENDED</bcp14>,
The use of the encryption of the header extensions are RECOMMENDED, unless there are known reasons, like RTP middleboxes performing voice-activit
unless there are known reasons, like RTP middleboxes performing voice y-based
activity based source selection or third party monitoring that will source selection or third-party monitoring that will
greatly benefit from the information, and this has been expressed greatly benefit from the information, and this has been expressed
using API or signalling. If further evidence are produced to show using API or signaling. If further evidence is produced to show
that information leakage is significant from audio level indications, that information leakage is significant from audio level indications,
then use of encryption needs to be mandated at that time.</t> then the use of encryption needs to be mandated at that time.</t>
<t>
<t> In multi-party communication scenarios using RTP middleboxes,
In multi-party communication scenarios using RTP Middleboxes; this the middleboxes are <bcp14>REQUIRED</bcp14>, by this protocol, to not weaken
middleboxes are REQUIRED, by this protocol, to not weaken the the
sessions' security. The middlebox SHOULD maintain the sessions' security. The middlebox <bcp14>SHOULD</bcp14> maintain
confidentiality, integrity and perform source authentication. The confidentiality, maintain integrity, and perform source authentication. The
middlebox MAY perform checks that prevents any endpoint participating middlebox <bcp14>MAY</bcp14> perform checks that prevent any endpoint partici
pating
in a conference to impersonate another. Some additional security in a conference to impersonate another. Some additional security
considerations regarding multi-party topologies can be found in considerations regarding multi-party topologies can be found in
<xref target="RFC7667"/></t> <xref target="RFC7667" format="default"/>.</t>
<t>
<t>
The CaptureID is created as part of the CLUE protocol. The CaptId 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 SDES item is used to convey the same CaptureID value in the SDES
item. When sending the SDES item the security consideration item. When sending the SDES item, the security considerations
specified in the security section of <xref target="RFC7941"/> and in the specified in <xref target="RFC7941" sectionFormat="of" section="6"/> and in t
communication security section of this memo <xref target="sect-7"/> are appli he
cable. communication security section of this memo (see <xref target="sect-7" format
Note that since the CaptureID is carried also in CLUE protocol ="default"/>) are applicable.
messages it is RECOMMENDED that this SDES item use at least similar Note that since the CaptureID is also carried in CLUE protocol
messages, it is <bcp14>RECOMMENDED</bcp14> that this SDES item use at least s
imilar
protection profiles as the CLUE protocol messages carried in the CLUE protection profiles as the CLUE protocol messages carried in the CLUE
data channel. .</t> data channel.</t>
</section>
</middle>
<back>
</section> <references>
<name>References</name>
<references>
<name>Normative References</name>
</middle> <!-- &I-D.ietf-clue-data-model-schema; is 8846-->
<reference anchor="RFC8846" target="http://www.rfc-editor.org/info/rfc8846">
<front>
<title>An XML Schema for the Controlling Multiple Streams for Telepr
esence (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"/>
<back> </reference>
<references title="Normative References">
&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;
</references>
<references title="Informative References">
<reference anchor="FIPS186"><front>
<title>Digital Signature Standard</title>
<author>
<organization>National Institute of Standards and Technology</organizatio
n>
</author>
<date month="July" year="2013"/> <!--draft-ietf-clue-framework-25 is 8845 -->
</front> <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>
<seriesInfo name="FIPS" value="PUB 186-4"/> <!-- draft-ietf-mmusic-sdp-bundle-negotiation (RFC 8843) -->
</reference> <reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843"
&I-D.ietf-avtcore-rtp-multi-stream; >
&I-D.ietf-clue-signaling; <front>
&RFC3264; <title>Negotiating Media Multiplexing Using the Session Description Prot
&RFC3550; ocol (SDP)</title>
&RFC3556; <author initials="C" surname="Holmberg" fullname="Christer Holmberg">
&RFC4566; <organization/>
&RFC4575; </author>
&RFC4585; <author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
&RFC4796; <organization/>
&RFC5124; </author>
&RFC5285; <author initials="C" surname="Jennings" fullname="Cullen Jennings">
&RFC5506; <organization/>
&RFC6562; </author>
&RFC7022; <date month="April" year="2020"/>
&RFC7201; </front>
&RFC7202; <seriesInfo name="RFC" value="8843"/>
&RFC7205; <seriesInfo name="DOI" value="10.17487/RFC8843"/>
&RFC7667; </reference>
</references>
</back>
</rfc> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3711.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5763.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5764.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6347.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6904.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7941.xml"/>
</references>
<references>
<name>Informative References</name>
<reference anchor="FIPS186" target="https://nvlpubs.nist.gov/nistpubs/FI
PS/NIST.FIPS.186-4.pdf">
<front>
<title>Digital Signature Standard (DSS)</title>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
<author>
<organization>National Institute of Standards and 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="DOI" value="10.17487/RFC8848"/>
</reference>
<!--draft-ietf-avtcore-rtp-multi-stream-11 is now RFC 8101-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8108.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3264.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3550.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3556.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4566.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4575.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4585.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4796.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.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/refer
ence.RFC.5506.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6562.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7022.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7201.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7202.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7205.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7667.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.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"/> help
ed draft
the security section.</t>
</section>
</back>
</rfc>
 End of changes. 104 change blocks. 
493 lines changed or deleted 530 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/