rfc8860xml2.original.xml   rfc8860.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
<?rfc tocdepth="3"?> docName="draft-ietf-avtcore-multi-media-rtp-session-13" number="8860"
<?rfc tocindent="yes"?> ipr="trust200902" updates="3550, 3551" obsoletes="" submissionType="IETF"
<?rfc symrefs="yes"?> consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true
<?rfc sortrefs="yes"?> " sortRefs="true" version="3">
<?rfc comments="yes"?> <!-- xml2rfc v2v3 conversion 2.35.0 -->
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-avtcore-multi-media-rtp-session-13"
ipr="trust200902" updates="3550, 3551">
<front> <front>
<title abbrev="Multiple Media Types in an RTP Session">Sending Multiple <title abbrev="Multiple Media Types in an RTP Session">Sending Multiple
Types of Media in a Single RTP Session</title> Types of Media in a Single RTP Session</title>
<seriesInfo name="RFC" value="8860"/>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund"> <author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Farogatan 6</street> <street>Torshamnsgatan 23</street>
<city>Stockholm</city>
<city>SE-164 80 Kista</city> <code>164 80</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<phone>+46 10 714 82 87</phone>
<email>magnus.westerlund@ericsson.com</email> <email>magnus.westerlund@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Colin Perkins" initials="C. " surname="Perkins"> <author fullname="Colin Perkins" initials="C. " surname="Perkins">
<organization>University of Glasgow</organization> <organization>University of Glasgow</organization>
<address> <address>
<postal> <postal>
<street>School of Computing Science</street> <street>School of Computing Science</street>
<city>Glasgow</city> <city>Glasgow</city>
<code>G12 8QQ</code> <code>G12 8QQ</code>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>csp@csperkins.org</email> <email>csp@csperkins.org</email>
</address> </address>
</author> </author>
<author fullname="Jonathan Lennox" initials="J." surname="Lennox"> <author fullname="Jonathan Lennox" initials="J." surname="Lennox">
<organization abbrev="Vidyo">Vidyo, Inc.</organization> <organization abbrev="8x8 / Jitsi">8x8, Inc. / Jitsi</organization>
<address> <address>
<postal> <postal>
<street>433 Hackensack Avenue</street> <city>Jersey City</city>
<street>Seventh Floor</street>
<city>Hackensack</city>
<region>NJ</region> <region>NJ</region>
<code>07302</code>
<code>07601</code> <country>United States of America</country>
<country>US</country>
</postal> </postal>
<email>jonathan.lennox@8x8.com</email>
<email>jonathan@vidyo.com</email>
</address> </address>
</author> </author>
<date month="January" year="2021"/>
<date day="18" month="December" year="2015"/> <keyword>Real-time</keyword>
<keyword>Multiplexing</keyword>
<workgroup>AVTCORE WG</workgroup> <keyword>Bundle</keyword>
<abstract> <abstract>
<t>This document specifies how an RTP session can contain RTP Streams <t>This document specifies how an RTP session can contain RTP streams
with media from multiple media types such as audio, video, and text. with media from multiple media types such as audio, video, and text.
This has been restricted by the RTP Specification, and thus this This has been restricted by the RTP specifications (RFCs 3550 and 3551), a
document updates RFC 3550 and RFC 3551 to enable this behaviour for nd thus this
document updates RFCs 3550 and 3551 to enable this behaviour for
applications that satisfy the applicability for using multiple media applications that satisfy the applicability for using multiple media
types in a single RTP session.</t> types in a single RTP session.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>The Real-time Transport Protocol <xref target="RFC3550"/> was <name>Introduction</name>
<t>The Real-time Transport Protocol <xref target="RFC3550" format="default
"/> was
designed to use separate RTP sessions to transport different types of designed to use separate RTP sessions to transport different types of
media. This implies that different transport layer flows are used for media. This implies that different transport-layer flows are used for
different RTP streams. For example, a video conferencing application different RTP streams. For example, a video conferencing application
might send audio and video traffic RTP flows on separate UDP ports. With might send audio and video traffic RTP flows on separate UDP ports. With
increased use of network address/port translation, firewalls, and other increased use of network address/port translation, firewalls, and other
middleboxes it is, however, becoming difficult to establish multiple middleboxes, it is, however, becoming difficult to establish multiple
transport layer flows between endpoints. Hence, there is pressure to transport-layer flows between endpoints. Hence, there is pressure to
reduce the number of concurrent transport flows used by RTP reduce the number of concurrent transport flows used by RTP
applications.</t> applications.</t>
<t>This memo updates <xref target="RFC3550" format="default"/> and <xref t
<t>This memo updates <xref target="RFC3550"/> and <xref arget="RFC3551" format="default"/> to allow multiple media types to be sent in a
target="RFC3551"/> to allow multiple media types to be sent in a single single
RTP session in certain cases, thereby reducing the number of transport RTP session in certain cases, thereby reducing the number of transport-lay
layer flows that are needed. It makes no changes to RTP behaviour when er flows that are needed. It makes no changes to RTP behaviour when
using multiple RTP streams containing media of the same type (e.g., using multiple RTP streams containing media of the same type (e.g.,
multiple audio streams or multiple video streams) in a single RTP multiple audio streams or multiple video streams) in a single RTP
session. However <xref target="I-D.ietf-avtcore-rtp-multi-stream"/> session. However, <xref target="RFC8108" format="default"/>
provides important clarifications to RTP behaviour in that case.</t> provides important clarifications to RTP behaviour in that case.</t>
<t>This memo is structured as follows. <xref target="sec_defn" format="def
<t>This memo is structured as follows. <xref target="sec:defn"/> defines ault"/> defines
terminology. <xref target="sec:background"/> further describes the terminology. <xref target="sec_background" format="default"/> further desc
background to, and motivation for, this memo and <xref ribes the
target="sec:applicability"/> describes the scenarios where this memo is background to, and motivation for, this memo; <xref target="sec_applicabil
applicable. <xref target="sec:base"/> discusses issues arising from the ity" format="default"/> describes the scenarios where this memo is
base RTP and RTCP specification when using multiple types of media in a applicable. <xref target="sec_base" format="default"/> discusses issues ar
single RTP session, while <xref target="sec:extn"/> considers the impact ising from the
of RTP extensions. We discuss signalling in <xref target="sec:sig"/>. base RTP and RTP Control Protocol (RTCP) specifications <xref
Finally, security considerations are discussed in <xref target="RFC3550"/> <xref target="RFC3551"/> when using multiple types of m
target="Security"/>.</t> edia in a
single RTP session, while <xref target="sec_extn" format="default"/> consi
ders the impact
of RTP extensions. We discuss signalling in <xref target="sec_sig" format=
"default"/>.
Finally, security considerations are discussed in <xref target="Security"
format="default"/>.</t>
</section> </section>
<section anchor="sec_defn" numbered="true" toc="default">
<section anchor="sec:defn" title="Terminology"> <name>Terminology</name>
<t>The terms Encoded Stream, Endpoint, Media Source, RTP Session, and <t>The terms "encoded stream", "endpoint", "media source", "RTP session",
RTP Stream are used as defined in <xref target="RFC7656"/>. We also and
"RTP stream" are used as defined in <xref target="RFC7656" format="default
"/>. We also
define the following terms:</t> define the following terms:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Media Type:</dt>
<t hangText="Media Type:">The general type of media data used by a <dd>The general type of media data used by a
real-time application. The media type corresponds to the value used real-time application. The media type corresponds to the value used
in the &lt;media&gt; field of an SDP m= line. The media types in the &lt;media&gt; field of a Session Description Protocol (SDP)
"m=" line. The media types
defined at the time of this writing are "audio", "video", "text", defined at the time of this writing are "audio", "video", "text",
"image", "application", and "message". <xref target="RFC4566"/> "image", "application", and "message" <xref target="RFC4566" format="d
<xref target="RFC6466"/></t> efault"/>
<xref target="RFC6466" format="default"/>.</dd>
<t hangText="Quality of Service (QoS):">Network mechanisms that are <dt>Quality of Service (QoS):</dt>
<dd>Network mechanisms that are
intended to ensure that the packets within a flow or with a specific intended to ensure that the packets within a flow or with a specific
marking are transported with certain properties.</t> marking are transported with certain properties.</dd>
</list></t> </dl>
<t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"OPTIONAL" in this document are to be interpreted as described in <xref ",
target="RFC2119"/>.</t> "<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 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="sec_background" numbered="true" toc="default">
<section anchor="sec:background" title="Background and Motivation"> <name>Background and Motivation</name>
<t>RTP was designed to support multimedia sessions, containing multiple <t>RTP was designed to support multimedia sessions, containing multiple
types of media sent simultaneously, by using multiple transport layer types of media sent simultaneously, by using multiple transport-layer
flows. The existence of network address translators, firewalls, and flows. The existence of network address translators, firewalls, and
other middleboxes complicates this, however, since a mechanism is needed other middleboxes complicates this, however, since a mechanism is needed
to ensure that all the transport layer flows needed by the application to ensure that all the transport-layer flows needed by the application
can be established. This has three consequences: <list style="numbers"> can be established. This has three consequences: </t>
<t>increased delay to establish a complete session, since each of <ol spacing="normal" type="1">
the transport layer flows needs to be negotiated and <li>increased delay to establish a complete session, since each of
established;</t> the transport-layer flows needs to be negotiated and
established;</li>
<t>increased state and resource consumption in the middleboxes that <li>increased state and resource consumption in the middleboxes that
can lead to unexpected behaviour when middlebox resource limits are can lead to unexpected behaviour when middlebox resource limits are
reached; and</t> reached; and</li>
<li>increased risk that a subset of the transport-layer flows will
<t>increased risk that a subset of the transport layer flows will
fail to be established, thus preventing the application from fail to be established, thus preventing the application from
communicating.</t> communicating.</li>
</list></t> </ol>
<t>Using fewer transport-layer flows can hence be seen to reduce the
<t>Using fewer transport layer flows can hence be seen to reduce the risk of communication failure and can lead to improved reliability and
risk of communication failure, and can lead to improved reliability and
performance.</t> performance.</t>
<t>One of the benefits of using multiple transport-layer flows is that
<t>One of the benefits of using multiple transport layer flows is that it makes it easy to use network-layer QoS
it makes it easy to use network layer quality of service (QoS)
mechanisms to give differentiated performance for different flows. mechanisms to give differentiated performance for different flows.
However, we note that many RTP-using application don't use network QoS However, we note that many applications that use RTP don't use network QoS
features, and don't expect or desire any separation in network treatment features and don't expect or desire any separation in network treatment
of their media packets, independent of whether they are audio, video or of their media packets, independent of whether they are audio, video, or
text. When an application has no such desire, it doesn't need to provide text. When an application has no such desire, it doesn't need to provide
a transport flow structure that simplifies flow based QoS.</t> a transport flow structure that simplifies flow-based QoS.</t>
<t>Given the above issues, it might seem appropriate for RTP-based <t>Given the above issues, it might seem appropriate for RTP-based
applications to send all their RTP streams bundled into one RTP session, applications to send all their RTP streams bundled into one RTP session,
running over a single transport layer flow. However, this is prohibited running over a single transport-layer flow. However, this is prohibited
by the RTP specification, because the design of RTP makes certain by the RTP specifications <xref target="RFC3550"/> <xref target="RFC3551"/
>, because the design of RTP makes certain
assumptions that can be incompatible with sending multiple media types assumptions that can be incompatible with sending multiple media types
in a single RTP session. Specifically, the RTP control protocol (RTCP) in a single RTP session. Specifically, the RTCP
timing rules assume that all RTP media flows in a single RTP session timing rules assume that all RTP media flows in a single RTP session
have broadly similar RTCP reporting and feedback requirements, which can have broadly similar RTCP reporting and feedback requirements, which can
be problematic when different types of media are multiplexed together. be problematic when different types of media are multiplexed together.
Various RTP extensions also make assumptions about SSRC use and RTCP Various RTP extensions also make assumptions about Synchronisation
Source (SSRC) use and RTCP
reporting that are incompatible with sending different media types in a reporting that are incompatible with sending different media types in a
single RTP session.</t> single RTP session.</t>
<t>This memo updates <xref target="RFC3550" format="default"/> and <xref t
<t>This memo updates <xref target="RFC3550"/> and <xref arget="RFC3551" format="default"/> to allow RTP sessions to contain more than on
target="RFC3551"/> to allow RTP sessions to contain more than one media e media
type in certain circumstances, and gives guidance on when it is safe to type in certain circumstances and gives guidance on when it is safe to
send multiple media types in a single RTP session.</t> send multiple media types in a single RTP session.</t>
</section> </section>
<section anchor="sec_applicability" numbered="true" toc="default">
<section anchor="sec:applicability" title="Applicability"> <name>Applicability</name>
<t>This specification has limited applicability, and anyone intending to <t>This specification has limited applicability, and anyone intending to
use it needs to ensure that their application and use case meets the use it needs to ensure that their application and use case meet the
following criteria: <list style="hanging"> following criteria: </t>
<t hangText="Equal treatment of media:">The use of a single RTP <dl newline="false" spacing="normal">
<dt>Equal treatment of media:</dt>
<dd>The use of a single RTP
session normally results in similar network treatment for all types session normally results in similar network treatment for all types
of media used within the session. Applications that require of media used within the session. Applications that require
significantly different network quality of service (QoS) or RTCP significantly different network QoS or RTCP
configuration for different RTP streams are better suited by sending configuration for different RTP streams are better suited to sending
those RTP streams in separate RTP session, using separate transport those RTP streams in separate RTP sessions, using separate
layer flows for each, since that gives greater flexibility. Further transport-layer flows for each, since that method provides greater flex
guidance on how to provide differential treatment for some media is ibility. Further
given in <xref target="I-D.ietf-avtcore-multiplex-guidelines"/> and guidance on how to provide differential treatment for some media strea
<xref target="RFC7657"/>.</t> ms is
given in <xref target="RFC8872" format="default"/> and
<t hangText="Compatible RTCP Behaviour:">The RTCP timing rules <xref target="RFC7657" format="default"/>.</dd>
<dt>Compatible RTCP behaviour:</dt>
<dd>The RTCP timing rules
enforce a single RTCP reporting interval for all participants in an enforce a single RTCP reporting interval for all participants in an
RTP session. Flows with very different media sending rate or RTCP RTP session. Flows with very different media sending rates or RTCP
feedback requirements cannot be multiplexed together, since this feedback requirements cannot be multiplexed together, since this
leads to either excessive or insufficient RTCP for some flows, leads to either excessive or insufficient RTCP for some flows,
depending on how the RTCP session bandwidth, and hence reporting depending on how the RTCP session bandwidth, and hence the reporting
interval, is configured. For example, it is likely infeasible to interval, are configured. For example, it is likely infeasible to
find a single RTCP configuration that simultaneously suits both a find a single RTCP configuration that simultaneously suits both a
low-rate audio flow with no feedback, and a high-quality video flow low-rate audio flow with no feedback and a high-quality video flow
with sophisticated RTCP-based feedback. Thus, combining these into a with sophisticated RTCP-based feedback. Thus, combining these into a
single RTP session is difficult and/or inadvisable.</t> single RTP session is difficult and/or inadvisable.</dd>
<dt>Signalled support:</dt>
<t hangText="Signalled Support:">The extensions defined in this memo <dd>The extensions defined in this memo
are not compatible with unmodified <xref are not compatible with unmodified endpoints that are compatible
target="RFC3550"/>-compatible endpoints. Their use requires with <xref target="RFC3550" format="default"/>. Their use requires
signalling and mutual agreement by all participants within an RTP signalling and mutual agreement by all participants within an RTP
session. This requirement can be a problem for signalling solutions session. This requirement can be a problem for signalling solutions
that can't negotiate with all participants. For declarative that can't negotiate with all participants. For declarative
signalling solutions, mandating that the session is using multiple signalling solutions, mandating that the session use multiple
media types in one RTP session can be a way of attempting to ensure media types in one RTP session can be a way of attempting to ensure
that all participants in the RTP session follow the requirement. that all participants in the RTP session follow the requirement.
However, for signalling solutions that lack methods for enforcing However, for signalling solutions that lack methods for enforcing
that a receiver supports a specific feature, this can still cause a requirement that a receiver support a specific feature, this can sti
issues.</t> ll cause
issues.</dd>
<t hangText="Consistent support for multiparty RTP sessions:">If it <dt>Consistent support for multiparty RTP sessions:</dt>
<dd><t>If it
is desired to send multiple types of media in a multiparty RTP is desired to send multiple types of media in a multiparty RTP
session, then all participants in that session need to support session, then all participants in that session need to support
sending multiple type of media in a single RTP session. It is not sending multiple types of media in a single RTP session. It is not
possible, in the general case, to implement a gateway that can possible, in the general case, to implement a gateway that can
interconnect an endpoint using multiple types of media sent using interconnect an endpoint that uses multiple types of media sent using
separate RTP sessions, with one or more endpoints that send multiple separate RTP sessions with one or more endpoints that send multiple
types of media in a single RTP session.</t> types of media in a single RTP session.</t>
<t>One reason for this is that the same SSRC value can safely be <t>One reason for this is that the same SSRC value can safely be
used for different streams in multiple RTP sessions, but when used for different streams in multiple RTP sessions, but when
collapsed to a single RTP session there is an SSRC collision. This collapsed to a single RTP session there is an SSRC collision. This
would not be an issue, since SSRC collision detection will resolve would not be an issue, since SSRC collision detection will resolve
the conflict, except that some RTP payload formats and extensions the conflict, except that some RTP payload formats and extensions
use matching SSRCs to identify related flows, and break when a use matching SSRCs to identify related flows and will break when a
single RTP session is used.</t> single RTP session is used.</t>
<t>A middlebox that remaps SSRC values when combining multiple RTP <t>A middlebox that remaps SSRC values when combining multiple RTP
sessions into one also needs to be aware of all possible RTCP packet sessions into one also needs to be aware of all possible RTCP packet
types that might be used, so that it can remap the SSRC values in types that might be used, so that it can remap the SSRC values in
those packets. This is impossible to do without restricting the set those packets. This is impossible to do without restricting the set
of RTCP packet types that can be used to those that are known by the of RTCP packet types that can be used to those that are known by the
middlebox. Such a middlebox might also have difficulty due to middlebox. Such a middlebox might also have difficulty due to
differences in configured RTCP bandwidth and other parameters differences in configured RTCP bandwidth and other parameters
between the RTP sessions.</t> between the RTP sessions.</t>
<t>Finally, the use of a middlebox that translates SSRC values can <t>Finally, the use of a middlebox that translates SSRC values can
negatively impact the possibility for loop detection, as SSRC/CSRC negatively impact the possibility of loop detection, as SSRC/CSRC
can't be used to detect the loops; instead some other RTP stream or (Contributing Source) can't be used to detect the loops; instead, some
media source identity name space that is common across all other RTP stream or
interconnect parts is needed.</t> media source identity namespace that is common across all
interconnected parts is needed.</t>
<t hangText="Ability to operate with limited payload type space:">An </dd>
<dt>Ability to operate with limited payload type space:</dt>
<dd>An
RTP session has only a single 7-bit payload type space for all its RTP session has only a single 7-bit payload type space for all its
payload type numbers. Some applications might find this space payload type numbers. Some applications might find this space to be
limiting when using different media types and RTP payload formats limiting (i.e., overly restrictive) when using different media types a
within a single RTP session.</t> nd RTP payload formats
within a single RTP session.</dd>
<t hangText="Avoids incompatible Extensions:">Some RTP and RTCP <dt>Avoidance of incompatible extensions:</dt>
<dd>Some RTP and RTCP
extensions rely on the existence of multiple RTP sessions and relate extensions rely on the existence of multiple RTP sessions and relate
RTP streams between sessions. Others report on particular media RTP streams between sessions. Others report on particular media
types, and cannot be used with other media types. Applications that types and cannot be used with other media types. Applications that
send multiple types of media into a single RTP session need to avoid send multiple types of media into a single RTP session need to avoid
such extensions.</t> such extensions.</dd>
</list></t> </dl>
</section> </section>
<section anchor="sec_base" numbered="true" toc="default">
<section anchor="sec:base" <name>Using Multiple Media Types in a Single RTP Session</name>
title="Using Multiple Media Types in a Single RTP Session">
<t>This section defines what needs to be done or avoided to make an RTP <t>This section defines what needs to be done or avoided to make an RTP
session with multiple media types function without issues.</t> session with multiple media types function without issues.</t>
<section numbered="true" toc="default">
<section title="Allowing Multiple Media Types in an RTP Session"> <name>Allowing Multiple Media Types in an RTP Session</name>
<t>Section 5.2 of <xref target="RFC3550">"RTP: A Transport Protocol <t><xref target="RFC3550" sectionFormat="of" section="5.2">
for Real-Time Applications"</xref> states:<list style="empty"> "RTP: A Transport Protocol for Real-Time Applications"</xref> states:</t>
<t>For example, in a teleconference composed of audio and video <blockquote>
media encoded separately, each medium SHOULD be carried in a <t>For example, in a teleconference composed of audio and video
media encoded separately, each medium <bcp14>SHOULD</bcp14> be carried
in a
separate RTP session with its own destination transport separate RTP session with its own destination transport
address.</t> address.</t>
<t>Separate audio and video streams <bcp14>SHOULD NOT</bcp14> be carried in a
<t>Separate audio and video streams SHOULD NOT be carried in a
single RTP session and demultiplexed based on the payload type or single RTP session and demultiplexed based on the payload type or
SSRC fields.</t> SSRC fields.</t>
</list></t> </blockquote>
<t>This specification changes both of these sentences. The first <t>This specification changes both of these sentences. The first
sentence is changed to:<list style="empty"> sentence is changed to:</t>
<t>For example, in a teleconference composed of audio and video <blockquote>
media encoded separately, each medium SHOULD be carried in a For example, in a teleconference composed of audio and video
media encoded separately, each medium <bcp14>SHOULD</bcp14> be carri
ed in a
separate RTP session with its own destination transport address, separate RTP session with its own destination transport address,
unless specification [RFCXXXX] is followed and the application unless the guidelines specified in [RFC8860] are followed and the ap
meets the applicability constraints.</t> plication
</list></t> meets the applicability constraints.
</blockquote>
<t>The second sentence is changed to:<list style="empty"> <t>The second sentence is changed to:</t>
<t>Separate audio and video media sources SHOULD NOT be carried in <blockquote>
a single RTP session, unless the guidelines specified in [RFCXXXX] Separate audio and video media sources <bcp14>SHOULD NOT</bcp14> be ca
are followed.</t> rried in
</list></t> a single RTP session, unless the guidelines specified in [RFC8860]
are followed.
<t>Second paragraph of Section 6 in <xref target="RFC3551">RTP Profile </blockquote>
for Audio and Video Conferences with Minimal Control</xref> says:</t> <t>The second paragraph of <xref target="RFC3551" sectionFormat="of" sec
tion="6">"RTP Profile for Audio and Video Conferences with Minimal Control"</xre
<t><list style="empty"> f> says:</t>
<t>The payload types currently defined in this profile are <blockquote>
The payload types currently defined in this profile are
assigned to exactly one of three categories or media types: audio assigned to exactly one of three categories or media types: audio
only, video only and those combining audio and video. The media only, video only and those combining audio and video. The media
types are marked in Tables 4 and 5 as "A", "V" and "AV", types are marked in Tables 4 and 5 as "A", "V" and "AV",
respectively. Payload types of different media types SHALL NOT be respectively. Payload types of different media types <bcp14>SHALL NO T</bcp14> be
interleaved or multiplexed within a single RTP session, but interleaved or multiplexed within a single RTP session, but
multiple RTP sessions MAY be used in parallel to send multiple multiple RTP sessions <bcp14>MAY</bcp14> be used in parallel to send
media types. An RTP source MAY change payload types within the multiple
media types. An RTP source <bcp14>MAY</bcp14> change payload types w
ithin the
same media type during a session. See the section "Multiplexing same media type during a session. See the section "Multiplexing
RTP Sessions" of RFC 3550 for additional explanation.</t> RTP Sessions" of RFC 3550 for additional explanation.
</list>This specification's purpose is to override that existing </blockquote>
SHALL NOT under certain conditions. Thus this sentence also has to be <t>This specification's purpose is to override the above-listed
changed to allow for multiple media type's payload types in the same "<bcp14>SHALL&nbsp;NOT</bcp14>" under certain conditions. Thus, this sen
session. The sentence containing "SHALL NOT" in the above paragraph is tence also has to be
changed to:<list style="empty"> changed to allow for multiple media types' payload types in the same
<t>Payload types of different media types SHALL NOT be interleaved session. The sentence containing "<bcp14>SHALL NOT</bcp14>" in the above
or multiplexed within a single RTP session unless [RFCXXXX] is paragraph is
used, and the application conforms to the applicability changed to:</t>
constraints. Multiple RTP sessions MAY be used in parallel to send <blockquote>
multiple media types.</t> Payload types of different media types <bcp14>SHALL NOT</bcp14> be int
</list></t> erleaved
or multiplexed within a single RTP session unless [RFC8860] is
<t>RFC-Editor Note: Please replace RFCXXXX with the RFC number of this used and the application conforms to the applicability
specification when assigned.</t> constraints. Multiple RTP sessions <bcp14>MAY</bcp14> be used in par
allel to send
multiple media types.
</blockquote>
</section> </section>
<section anchor="sec_demuxing" numbered="true" toc="default">
<section anchor="sec:demuxing" <name>Demultiplexing Media Types within an RTP Session</name>
title="Demultiplexing media types within an RTP session"> <t>When receiving packets from a transport-layer flow, an endpoint
<t>When receiving packets from a transport layer flow, an endpoint will first separate the RTP and RTCP packets from the non-RTP packets
will first separate the RTP and RTCP packets from the non-RTP packets,
and pass them to the RTP/RTCP protocol handler. The RTP and RTCP and pass them to the RTP/RTCP protocol handler. The RTP and RTCP
packets are then demultiplexed based on their SSRC into the different packets are then demultiplexed into the different
RTP streams. For each RTP stream, incoming RTCP packets are processed, RTP streams based on their SSRC. For each RTP stream, incoming RTCP pack
ets are processed,
and the RTP payload type is used to select the appropriate media and the RTP payload type is used to select the appropriate media
decoder. This process remains the same irrespective of whether decoder. This process remains the same irrespective of whether
multiple media types are sent in a single RTP session or not.</t> multiple media types are sent in a single RTP session or not.</t>
<t>As explained below, it is important to note that the RTP payload <t>As explained below, it is important to note that the RTP payload
type is never used to distinguish RTP streams. The RTP packets are type is never used to distinguish RTP streams. The RTP packets are
demultiplexed into RTP streams based on their SSRC, then the RTP demultiplexed into RTP streams based on their SSRC; the RTP
payload type is used to select the correct media decoding pathway for payload type is then used to select the correct media-decoding pathway f
or
each RTP stream.</t> each RTP stream.</t>
</section> </section>
<section anchor="sec-source-restrcitctions" numbered="true" toc="default">
<section anchor="sec-source-restrcitctions" <name>Per-SSRC Media Type Restrictions</name>
title="Per-SSRC Media Type Restrictions">
<t>An SSRC in an RTP session can change between media formats of the <t>An SSRC in an RTP session can change between media formats of the
same type, subject to certain restrictions <xref target="RFC7160"/>, same type, subject to certain restrictions <xref target="RFC7160" format
but MUST NOT change media type during its lifetime. For example, an ="default"/>,
SSRC can change between different audio formats, but cannot start but <bcp14>MUST NOT</bcp14> change its media type during its lifetime. F
sending audio then change to sending video. The lifetime of an SSRC or example, an
ends when an RTCP BYE packet for that SSRC is sent, or when it ceases SSRC can change between different audio formats, but it cannot start
sending audio and then change to sending video. The lifetime of an SSRC
ends when an RTCP BYE packet for that SSRC is sent or when it ceases
transmission for long enough that it times out for the other transmission for long enough that it times out for the other
participants in the session.</t> participants in the session.</t>
<t>The main motivation is that a given SSRC has its own RTP timestamp <t>The main motivation is that a given SSRC has its own RTP timestamp
and sequence number spaces. The same way that you can't send two and sequence number spaces. The same way that you can't send two
encoded streams of audio with the same SSRC, you can't send one encoded streams of audio with the same SSRC, you can't send one
encoded audio and one encoded video stream with the same SSRC. Each encoded audio and one encoded video stream with the same SSRC. Each
encoded stream when made into an RTP stream needs to have the sole encoded stream, when made into an RTP stream, needs to have sole
control over the sequence number and timestamp space. If not, one control over the sequence number and timestamp space. If not, one
would not be able to detect packet loss for that particular encoded would not be able to detect packet loss for that particular encoded
stream. Nor can one easily determine which clock rate a particular stream, nor could one easily determine which clock rate a particular
SSRCs timestamp will increase with. For additional arguments why RTP SSRC's timestamp will increase with. For additional arguments regarding
payload type based multiplexing of multiple media sources doesn't why multiplexing of multiple media sources that is based on RTP payload t
work, see <xref target="I-D.ietf-avtcore-multiplex-guidelines"/>.</t> ype doesn't
work, see <xref target="RFC8872" format="default"/>.</t>
<t>Within an RTP session where multiple media types have been <t>Within an RTP session where multiple media types have been
configured for use, an SSRC can only send one type of media during its configured for use, an SSRC can only send one type of media during its
lifetime (i.e., it can switch between different audio codecs, since lifetime (i.e., it can switch between different audio codecs, since
those are both the same type of media, but cannot switch between audio those are both the same type of media, but it cannot switch between audi
and video). Different SSRCs MUST be used for the different media o
and video). Different SSRCs <bcp14>MUST</bcp14> be used for the differen
t media
sources, the same way multiple media sources of the same media type sources, the same way multiple media sources of the same media type
already have to do. The payload type will inform a receiver which already have to do. The payload type will inform a receiver which
media type the SSRC is being used for. Thus the payload type MUST be media type the SSRC is being used for. Thus, the payload type <bcp14>MUS
unique across all of the payload configurations independent of media T</bcp14> be
unique across all of the payload configurations, independent of the medi
a
type that is used in the RTP session.</t> type that is used in the RTP session.</t>
</section> </section>
<section anchor="sec.rtcp" numbered="true" toc="default">
<!-- This adds nothing compared to the later sections (csp) <name>RTCP Considerations</name>
<section title="Payload Type Applicability">
<t>Most Payload Types have a native media type, like an audio codec is
natural belonging to the audio media type. However, there exist a
number of RTP payload types that don't have a native media type. For
example, transport robustness mechanisms like <xref
target="RFC4588">RTP Retransmission</xref> and <xref
target="RFC5109">Generic FEC</xref> inherit their media type from what
they protect. RTP Retransmission is explicitly bound to the payload
type it is protecting, and thus will inherit it. However Generic FEC
is a excellent example of an RTP payload type that has no natural
media type. The media type for what it protects is not relevant as it
is the recovered RTP packets that have a particular media type, and
thus Generic FEC is best categorized as an application media type.</t>
<t>The above discussion is relevant to what limitations exist for RTP
payload type usage within an RTP session that has multiple media
types. In fact <xref target="sec-generic-fec">this document</xref>
suggest that for usage of Generic FEC (XOR-based) as defined in RFC
5109 can actually use a single media type when used with independent
RTP sessions for source and repair data. <list style="hanging">
<t>Note a particular SSRC carrying Generic FEC will clearly only
protect a specific SSRC and thus that instance is bound to the
SSRC's media type. For this specific case, it is possible to have
one be applicable to both. However, in cases when the signalling
is setup to enable fall back to using separate RTP sessions, then
using a different media type, e.g. application, than the media
being protected can create issues.</t>
</list></t>
</section>
-->
<section anchor="sec.rtcp" title="RTCP Considerations">
<t>When sending multiple types of media that have different rates in a <t>When sending multiple types of media that have different rates in a
single RTP session, endpoints MUST follow the guidelines for handling single RTP session, endpoints <bcp14>MUST</bcp14> follow the guidelines
RTCP described in Section 7 of <xref for handling
target="I-D.ietf-avtcore-rtp-multi-stream"/>.</t> RTCP as provided in <xref target="RFC8108" sectionFormat="of" section="7
"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec_extn" numbered="true" toc="default">
<section anchor="sec:extn" title="Extension Considerations"> <name>Extension Considerations</name>
<t>This section outlines known issues and incompatibilities with RTP and <t>This section outlines known issues and incompatibilities with RTP and
RTCP extensions when multiple media types are used in a single RTP RTCP extensions when multiple media types are used in a single RTP
sessions. Future extensions to RTP and RTCP need to consider, and session. Future extensions to RTP and RTCP need to consider, and
document, any potential incompatibility.</t> document, any potential incompatibilities.</t>
<section anchor="sec-rtx" numbered="true" toc="default">
<section anchor="sec-rtx" title="RTP Retransmission Payload Format"> <name>RTP Retransmission Payload Format</name>
<t>The RTP Retransmission Payload Format <xref target="RFC4588"/> can <t>The RTP retransmission payload format <xref target="RFC4588" format="
operate in either SSRC-multiplexed mode or session-multiplex mode.</t> default"/> can
operate in either SSRC-multiplexed mode or session-multiplexed mode.</t>
<t>In SSRC-multiplexed mode, retransmitted RTP packets are sent in the <t>In SSRC-multiplexed mode, retransmitted RTP packets are sent in the
same RTP session as the original packets, but use a different SSRC same RTP session as the original packets but use a different SSRC
with the same RTCP SDES CNAME. If each endpoint sends only a single with the same RTCP Source Description (SDES) CNAME. If each endpoint sen
ds only a single
original RTP stream and a single retransmission RTP stream in the original RTP stream and a single retransmission RTP stream in the
session, this is sufficient. If an endpoint sends multiple original session, this is sufficient. If an endpoint sends multiple original
and retransmission RTP streams, as would occur when sending multiple and retransmission RTP streams, as would occur when sending multiple
media types in a single RTP session, then each original RTP stream and media types in a single RTP session, then each original RTP stream and
the retransmission RTP stream have to be associated using heuristics. the retransmission RTP stream have to be associated using heuristics.
By having retransmission requests outstanding for only one SSRC not By having retransmission requests outstanding for only one SSRC not
yet mapped, a receiver can determine the binding between original and yet mapped, a receiver can determine the binding between the original an
retransmission RTP stream. Another alternative is the use of different d
retransmission RTP streams. Another alternative is the use of different
RTP payload types, allowing the signalled "apt" (associated payload RTP payload types, allowing the signalled "apt" (associated payload
type) parameter of the RTP retransmission payload format to be used to type) parameter <xref target="RFC4588"/> of the RTP retransmission paylo ad format to be used to
associate retransmitted and original packets.</t> associate retransmitted and original packets.</t>
<t>Session-multiplexed mode sends the retransmission RTP stream in a <t>Session-multiplexed mode sends the retransmission RTP stream in a
separate RTP session to the original RTP stream, but using the same separate RTP session to the original RTP stream, but using the same
SSRC for each, with association being done by matching SSRCs between SSRC for each, with the association being done by matching SSRCs between
the two sessions. This is unaffected by the use of multiple media the two sessions. This is unaffected by the use of multiple media
types in a single RTP session, since each media type will be sent types in a single RTP session, since each media type will be sent
using a different SSRC in the original RTP session, and the same SSRCs using a different SSRC in the original RTP session, and the same SSRCs
can be used in the retransmission session, allowing the streams to be can be used in the retransmission session, allowing the streams to be
associated. This can be signalled using SDP with the BUNDLE <xref associated. This can be signalled using SDP with the BUNDLE grouping
target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> and FID grouping extension <xref target="RFC8843" format="default"/> and the Flow Identifi
<xref target="RFC5888"/> extensions. These SDP extensions require each cation (FID)
grouping extension <xref target="RFC5888" format="default"/>. These SDP e
xtensions require each
"m=" line to only be included in a single FID group, but the RTP "m=" line to only be included in a single FID group, but the RTP
retransmission payload format uses FID groups to indicate the m= lines retransmission payload format uses FID groups to indicate the "m=" lines
that form an original and retransmission pair. Accordingly, when using that form an original and retransmission pair. Accordingly, when using
the BUNDLE extension to allow multiple media types to be sent in a the BUNDLE extension to allow multiple media types to be sent in a
single RTP session, each original media source (m= line) that is single RTP session, each original media source ("m=" line) that is
retransmitted needs a corresponding m= line in the retransmission RTP retransmitted needs a corresponding "m=" line in the retransmission RTP
session. In case there are multiple media lines for retransmission, session. If there are multiple media lines for retransmission,
these media lines will form an independent BUNDLE group from the these media lines will form an independent BUNDLE group from the
BUNDLE group with the source streams.</t> BUNDLE group with the source streams.</t>
<t>An example SDP fragment showing the grouping structures is provided <t>An example SDP fragment showing the grouping structures is provided
in <xref target="fig-rtx-session"/>. This example is not legal SDP and in <xref target="fig-rtx-session" format="default"/>. This example is no t legal SDP, and
only the most important attributes have been left in place. Note that only the most important attributes have been left in place. Note that
this SDP is not an initial BUNDLE offer. As can be seen there are two this SDP is not an initial BUNDLE offer. As can be seen in this example,
bundle groups, one for the source RTP session and one for the there are two
retransmissions. Then each of the media sources are grouped with its bundle groups -- one for the source RTP session and one for the
retransmissions. Then, each of the media sources is grouped with its
retransmission flow using FID, resulting in three more groupings.</t> retransmission flow using FID, resulting in three more groupings.</t>
<figure anchor="fig-rtx-session">
<figure anchor="fig-rtx-session" <name>SDP Example of Session-Multiplexed RTP Retransmission</name>
title="SDP example of Session Multiplexed RTP Retransmission"> <sourcecode name="sdp-example" type="sdp"><![CDATA[ a=group:BUND
<artwork><![CDATA[ a=group:BUNDLE foo bar fiz LE foo bar fiz
a=group:BUNDLE zoo kelp glo a=group:BUNDLE zoo kelp glo
a=group:FID foo zoo a=group:FID foo zoo
a=group:FID bar kelp a=group:FID bar kelp
a=group:FID fiz glo a=group:FID fiz glo
m=audio 10000 RTP/AVP 0 m=audio 10000 RTP/AVP 0
a=mid:foo a=mid:foo
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 10000 RTP/AVP 31 m=video 10000 RTP/AVP 31
a=mid:bar a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
skipping to change at line 524 skipping to change at line 452
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=fmtp:99 apt=0;rtx-time=3000 a=fmtp:99 apt=0;rtx-time=3000
a=mid:zoo a=mid:zoo
m=video 40000 RTP/AVPF 100 m=video 40000 RTP/AVPF 100
a=rtpmap:100 rtx/90000 a=rtpmap:100 rtx/90000
a=fmtp:199 apt=31;rtx-time=3000 a=fmtp:199 apt=31;rtx-time=3000
a=mid:kelp a=mid:kelp
m=video 40000 RTP/AVPF 100 m=video 40000 RTP/AVPF 100
a=rtpmap:100 rtx/90000 a=rtpmap:100 rtx/90000
a=fmtp:199 apt=31;rtx-time=3000 a=fmtp:199 apt=31;rtx-time=3000
a=mid:glo a=mid:glo]]></sourcecode>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="sec-generic-fec" numbered="true" toc="default">
<section anchor="sec-generic-fec" <name>RTP Payload Format for Generic FEC</name>
title="RTP Payload Format for Generic FEC"> <t>The RTP payload format for generic Forward Error Correction (FEC),
<t>The RTP Payload Format for Generic Forward Error Correction (FEC) as defined in <xref target="RFC5109" format="default"/> (and its predece
<xref target="RFC5109"/> (and its predecessor <xref ssor, <xref target="RFC2733" format="default"/>), can either send the FEC stream
target="RFC2733"/>) can either send the FEC stream as a separate RTP as a separate RTP
stream, or it can send the FEC combined with the original RTP stream stream or send the FEC combined with the original RTP stream
as a redundant encoding <xref target="RFC2198"/>.</t> as a redundant encoding <xref target="RFC2198" format="default"/>.</t>
<t>When sending FEC as a separate stream, the RTP payload format for
<t>When sending FEC as a separate stream, the RTP Payload Format for
generic FEC requires that FEC stream to be sent in a separate RTP generic FEC requires that FEC stream to be sent in a separate RTP
session to the original stream, using the same SSRC, with the FEC session to the original stream, using the same SSRC, with the FEC
stream being associated by matching the SSRC between sessions. The RTP stream being associated by matching the SSRC between sessions. The RTP
session used for the original streams can include multiple RTP session used for the original streams can include multiple RTP
streams, and those RTP streams can use multiple media types. The streams, and those RTP streams can use multiple media types. The
repair session only needs one RTP Payload type to indicate FEC data, repair session only needs one RTP payload type to indicate FEC data,
irrespective of the number of FEC streams sent, since the SSRC is used irrespective of the number of FEC streams sent, since the SSRC is used
to associate the FEC streams with the original streams. Hence, it is to associate the FEC streams with the original streams. Hence, it is
RECOMMENDED that the FEC stream use the "application/ulpfec" media <bcp14>RECOMMENDED</bcp14> that the FEC stream use the "application/ulpf
type for <xref target="RFC5109"/>, and the "application/parityfec" ec" media
media type for <xref target="RFC2733"/>. It is legal, but NOT type in the case of support for <xref target="RFC5109" format="default"/
RECOMMENDED, to send FEC streams using media specific payload format > and the "application/&wj;parityfec"
media type in the case of support for <xref target="RFC2733" format="def
ault"/>. It is legal, but <bcp14>NOT
RECOMMENDED</bcp14>, to send FEC streams using media-specific payload fo
rmat
names (e.g., using both the "audio/ulpfec" and "video/ulpfec" payload names (e.g., using both the "audio/ulpfec" and "video/ulpfec" payload
formats for a single RTP session containing both audio and video formats for a single RTP session containing both audio and video
flows), since this unnecessarily uses up RTP payload type values, and flows), since this (1)&nbsp;unnecessarily uses up RTP payload type value
adds no value for demultiplexing since there might be multiple streams s and
(2)&nbsp;adds no value for demultiplexing because there might be multipl
e streams
of the same media type).</t> of the same media type).</t>
<t>The combination of an original RTP session using multiple media <t>The combination of an original RTP session using multiple media
types with an associated generic FEC session can be signalled using types with an associated generic FEC session can be signalled using
SDP with the BUNDLE extension <xref SDP with the BUNDLE extension <xref target="RFC8843" format="default"/>.
target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>. In this case, the In this case, the
RTP session carrying the FEC streams will be its own BUNDLE group. The RTP session carrying the FEC streams will be its own BUNDLE group. The
m= line for each original stream and the m= line for the corresponding "m=" line for each original stream and the "m=" line for the correspondi
FEC stream are grouped using the SDP grouping framework using either ng
the <xref target="RFC5956">FEC-FR</xref> grouping or, for backwards FEC stream are grouped using the SDP Grouping Framework, using either
compatibility, the FEC <xref target="RFC4756"/> grouping. This is the <xref target="RFC5956" format="default">FEC-FR grouping</xref> or, f
or backwards
compatibility, the FEC grouping <xref target="RFC4756" format="default"/
>. This is
similar to the situation that arises for RTP retransmission with similar to the situation that arises for RTP retransmission with
session multiplexing discussed in <xref target="sec-rtx"/>.</t> session-based multiplexing as discussed in <xref target="sec-rtx" format
="default"/>.</t>
<t>The <xref target="RFC5576">Source-Specific Media Attributes</xref> <t>The <xref target="RFC5576" format="default">source-specific media
specification defines an SDP extension (the "FEC" semantic of the attributes specification</xref>
defines an SDP extension (the "FEC" semantic of the
"ssrc-group" attribute) to signal FEC relationships between multiple "ssrc-group" attribute) to signal FEC relationships between multiple
RTP streams within a single RTP session. This cannot be used with RTP streams within a single RTP session. This cannot be used with
generic FEC, since the FEC repair packets need to have the same SSRC generic FEC, since the FEC repair packets need to have the same SSRC
value as the source packets being protected. There was work on an value as the source packets being protected.
Unequal Layer Protection (ULP) extension to allow it be use FEC RTP There existed a proposal (now abandoned) for an Uneven Level Protection (ULP)
streams within the same RTP Session as the source stream <xref extension to enable transmission of the FEC RTP
target="I-D.lennox-payload-ulp-ssrc-mux"/>.</t> streams within the same RTP session as the source stream <xref
target="I-D.lennox-payload-ulp-ssrc-mux" format="default"/>.</t>
<t>When the FEC is sent as a redundant encoding, the considerations in <t>When the FEC is sent as a redundant encoding, the considerations in
<xref target="sec-red"/> apply.</t> <xref target="sec-red" format="default"/> apply.</t>
</section> </section>
<section anchor="sec-red" numbered="true" toc="default">
<section anchor="sec-red" title="RTP Payload Format for Redundant Audio"> <name>RTP Payload Format for Redundant Audio</name>
<t>The RTP Payload Format for Redundant Audio <xref target="RFC2198"/> <t>The RTP payload format for redundant audio <xref target="RFC2198" for
mat="default"/>
can be used to protect audio streams. It can also be used along with can be used to protect audio streams. It can also be used along with
the generic FEC payload format to send original and repair data in the the generic FEC payload format to send original and repair data in the
same RTP packets. Both are compatible with RTP sessions containing same RTP packets. Both are compatible with RTP sessions containing
multiple media types.</t> multiple media types.</t>
<t>This payload format requires each different redundant encoding to use
<t>This payload format requires each different redundant encoding use
a different RTP payload type number. When used with generic FEC in a different RTP payload type number. When used with generic FEC in
sessions that contain multiple media types, this requires each media sessions that contain multiple media types, this requires each media
type to use a different payload type for the FEC stream. For example, type to use a different payload type for the FEC stream. For example,
if audio and text are sent in a single RTP session with generic ULP if audio and text are sent in a single RTP session with generic ULP
FEC sent as a redundant encoding for each, then payload types need to FEC sent as a redundant encoding for each, then payload types need to
be assigned for FEC using the audio/ulpfec and text/ulpfec payload be assigned for FEC using the audio/ulpfec and text/&wj;ulpfec payload
formats. If multiple original payload types are used in the session, formats. If multiple original payload types are used in the session,
different redundant payload types need to be allocated for each one. different redundant payload types need to be allocated for each one.
This has potential to rapidly exhaust the available RTP payload type This has potential to rapidly exhaust the available RTP payload type
numbers.</t> numbers.</t>
</section> </section>
</section> </section>
<section anchor="sec_sig" numbered="true" toc="default">
<section anchor="sec:sig" title="Signalling"> <name>Signalling</name>
<t>Establishing a single RTP session using multiple media types requires <t>Establishing a single RTP session using multiple media types requires
signalling. This signalling has to:<list style="numbers"> signalling. This signalling has to:</t>
<t>ensure that any participant in the RTP session is aware that this <ol spacing="normal" type="1">
is an RTP session with multiple media types;</t> <li>ensure that any participant in the RTP session is aware that this
is an RTP session with multiple media types;</li>
<t>ensure that the payload types in use in the RTP session are using <li>ensure that the payload types in use in the RTP session are using
unique values, with no overlap between the media types;</t> unique values, with no overlap between the media types;</li>
<li>ensure that RTP session-level parameters -- for example, the RTCP RR
<t>ensure RTP session level parameters, for example the RTCP RR and and
RS bandwidth modifiers, the RTP/AVPF trr-int parameter, transport RS bandwidth modifiers <xref target="RFC3556"/>, the RTP/AVPF
protocol, RTCP extensions in use, and any security parameters, are trr-int parameter <xref target="RFC4585"/>, transport
consistent across the session; and</t> protocol, RTCP extensions in use, and any security parameters -- are
consistent across the session; and</li>
<t>ensure that RTP and RTCP functions that can be bound to a <li>ensure that RTP and RTCP functions that can be bound to a
particular media type are reused where possible, rather than particular media type are reused where possible, rather than
configuring multiple code-points for the same thing.</t> configuring multiple code points for the same thing.</li>
</list></t> </ol>
<t>When using SDP signalling, the BUNDLE extension <xref target="RFC8843"
<t>When using SDP signalling, the BUNDLE extension <xref format="default"/> is used to signal RTP
target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> is used to signal RTP
sessions containing multiple media types.</t> sessions containing multiple media types.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>RTP provides a range of strong security mechanisms that can be used <t>RTP provides a range of strong security mechanisms that can be used
to secure sessions <xref target="RFC7201"/>, <xref target="RFC7202"/>. to secure sessions <xref target="RFC7201" format="default"/> <xref target= "RFC7202" format="default"/>.
The majority of these are independent of the type of media sent in the The majority of these are independent of the type of media sent in the
RTP session; however it is important to check that the security RTP session; however, it is important to check that the security
mechanism chosen is compatible with all types of media sent within the mechanism chosen is compatible with all types of media sent within the
session.</t> session.</t>
<t>Sending multiple media types in a single RTP session will generally <t>Sending multiple media types in a single RTP session will generally
require that all use the same security mechanism, whereas media sent require that all use the same security mechanism, whereas media sent
using different RTP sessions can be secured in different ways. When using different RTP sessions can be secured in different ways. When
different media types have different security requirements, it might be different media types have different security requirements, it might be
necessary to send them using separate RTP sessions to meet those necessary to send them using separate RTP sessions to meet those
different requirements. This can have significant costs in terms of different requirements. This can have significant costs in terms of
resource usage, session set-up time, etc.</t> resource usage, session setup time, etc.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo makes no request of IANA.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="Acknowledgements" title="Acknowledgements"> <name>IANA Considerations</name>
<t>The authors would like to thank Christer Holmberg, Gunnar <t>This document has no IANA actions.</t>
Hellstr&ouml;m, Charles Eckel, Tolga Asveren, Warren Kumari, and Meral
Shirazipour for their feedback on the document.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.3550'?>
<?rfc include='reference.RFC.3551'?>
<?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?> <displayreference target="I-D.lennox-payload-ulp-ssrc-mux" to="FEC-Src-Multiplex
ing"/>
<?rfc include='reference.I-D.ietf-avtcore-rtp-multi-stream'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-avtcore-multiplex-guidelines'?>
<?rfc include='reference.RFC.7656'?>
<?rfc include='reference.RFC.7657'?>
<?rfc include='reference.I-D.lennox-payload-ulp-ssrc-mux'?>
<?rfc include='reference.RFC.2198'?>
<?rfc include='reference.RFC.2733'?>
<?rfc include='reference.RFC.4566'?>
<?rfc include='reference.RFC.4588'?>
<?rfc include='reference.RFC.4756'?>
<?rfc include='reference.RFC.5109'?>
<?rfc include='reference.RFC.5576'?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3550.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3551.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml"/>
<?rfc include='reference.RFC.5888'?> <!-- 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 Prot
ocol (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="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8843"/>
<seriesInfo name="DOI" value="10.17487/RFC8843"/>
</reference>
<?rfc include='reference.RFC.5956'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8108.xml"/>
<?rfc include='reference.RFC.6466'?> </references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3556.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4585.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7656.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7657.xml"/>
<?rfc include='reference.RFC.7160'?> <!-- draft-ietf-avtcore-multiplex-guidelines (RFC 8872) -->
<reference anchor="RFC8872" target="https://www.rfc-editor.org/info/rfc8872">
<front>
<title>Guidelines for Using the Multiplexing Features of RTP to Support
Multiple Media Streams</title>
<author initials="M" surname="Westerlund" fullname="Magnus Westerlund">
<organization/>
</author>
<author initials="B" surname="Burman" fullname="Bo Burman">
<organization/>
</author>
<author initials="C" surname="Perkins" fullname="Colin Perkins">
<organization/>
</author>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
<organization/>
</author>
<author initials="R" surname="Even" fullname="Roni Even">
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8872"/>
<seriesInfo name="DOI" value="10.17487/RFC8872"/>
</reference>
<?rfc include='reference.RFC.7201'?> <!-- draft-lennox-payload-ulp-ssrc-mux (Expired) -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.draft-lennox-payload-ulp-ssrc-mux-00.xml"/>
<?rfc include='reference.RFC.7202'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2198.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2733.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4566.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4588.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4756.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5109.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5576.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5888.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5956.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6466.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7160.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7201.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7202.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Christer
Holmberg"/>, <contact fullname="Gunnar Hellström"/>, <contact
fullname="Charles Eckel"/>, <contact fullname="Tolga Asveren"/>,
<contact fullname="Warren Kumari"/>, and <contact fullname="Meral
Shirazipour"/> for their feedback on this document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 131 change blocks. 
436 lines changed or deleted 490 lines changed or added

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