rfc8843xml2.original.xml   rfc8843.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version='1.0' encoding='utf-8'?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902"
<?rfc sortrefs="no" ?> number="8843" category="std"
<rfc ipr="pre5378Trust200902" category="std" docName="draft-ietf-mmusic-sdp-bund docName="draft-ietf-mmusic-sdp-bundle-negotiation-54" updates="3264, 5888,
le-negotiation-54.txt" updates="3264,5888,7941" submissionType="IETF" xml:lang=" 7941" submissionType="IETF" consensus="true" xml:lang="en" obsoletes="" tocInclu
en"> de="true" sortRefs="true" symRefs="true" version="3" >
<front> <!-- xml2rfc v2v3 conversion 2.36.0 -->
<title abbrev="Bundled media">
<front>
<title abbrev="Bundled Media">
Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
</title> </title>
<author initials="C.H." surname="Holmberg" fullname="Christer Holmberg"> <seriesInfo name="RFC" value="8843"/>
<organization>Ericsson</organization> <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<address> <organization>Ericsson</organization>
<postal> <address>
<street>Hirsalantie 11</street> <postal>
<code>02420</code> <street>Hirsalantie 11</street>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country> <city>Jorvas</city>
</postal> <country>Finland</country>
<email>christer.holmberg@ericsson.com</email> </postal>
</address> <email>christer.holmberg@ericsson.com</email>
</address>
</author> </author>
<author fullname="Harald Tveit Alvestrand" initials="H." surname="Alvestrand
<author fullname="Harald Tveit Alvestrand" surname="Alvestrand" initials="H. T ">
."> <organization>Google</organization>
<organization>Google</organization> <address>
<address> <postal>
<postal> <street>Kungsbron 2</street>
<street>Kungsbron 2</street> <city>Stockholm</city>
<city>Stockholm</city> <code>11122</code>
<code>11122</code> <country>Sweden</country>
<country>Sweden</country> </postal>
</postal> <email>harald@alvestrand.no</email>
<email>harald@alvestrand.no</email> </address>
</address>
</author> </author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<author fullname="Cullen Jennings" initials="C." surname="Jennings"> <organization>Cisco</organization>
<organization>Cisco</organization> <address>
<address> <postal>
<postal> <street>400 3rd Avenue SW, Suite 350</street>
<street>400 3rd Avenue SW, Suite 350</street> <city>Calgary</city>
<city>Calgary</city> <region>AB</region>
<region>AB</region> <code>T2P 4H2</code>
<code>T2P 4H2</code> <country>Canada</country>
<country>Canada</country> </postal>
</postal> <email>fluffy@iii.ca</email>
<email>fluffy@iii.ca</email>
</address> </address>
</author> </author>
<date month="May" year="2020"/>
<date year="2018" />
<area>Transport</area> <area>Transport</area>
<workgroup>MMUSIC Working Group</workgroup> <workgroup>MMUSIC Working Group</workgroup>
<keyword>RTP</keyword> <keyword>RTP</keyword>
<keyword>SDP</keyword> <keyword>SDP</keyword>
<keyword>Bundle</keyword> <keyword>Bundle</keyword>
<keyword>Multiplexing</keyword> <keyword>Multiplexing</keyword>
<keyword>RTCWEB</keyword> <keyword>RTCWEB</keyword>
<keyword>CLUE</keyword> <keyword>CLUE</keyword>
<keyword>RTCWEB</keyword> <keyword>RTCWEB</keyword>
<keyword>MMUSIC</keyword> <keyword>MMUSIC</keyword>
<keyword>AVT</keyword> <keyword>AVT</keyword>
<keyword>WEB</keyword> <keyword>WEB</keyword>
<keyword>Browser</keyword> <keyword>Browser</keyword>
<abstract> <abstract>
<t> <t>
This specification defines a new Session Description This specification defines a new Session Description
Protocol (SDP) Grouping Framework extension, 'BUNDLE'. Protocol (SDP) Grouping Framework extension called 'BUNDLE'.
The extension can be used with the SDP Offer/Answer mechanism The extension can be used with the SDP Offer/Answer mechanism
to negotiate the usage of a single transport (5-tuple) for to negotiate the usage of a single transport (5-tuple) for
sending and receiving media described by multiple SDP media descriptions sending and receiving media described by multiple SDP media descriptions
("m=" sections). Such transport is referred to as a BUNDLE transport, ("m=" sections). Such transport is referred to as a BUNDLE transport,
and the media is referred to as bundled media. The "m=" sections that and the media is referred to as bundled media. The "m=" sections that
use the BUNDLE transport form a BUNDLE group. use the BUNDLE transport form a BUNDLE group.
</t> </t>
<t> <t>
This specification defines a new RTP Control Protocol (RTCP) Source
Description (SDES) item and a new RTP header extension.</t>
<t>
This specification updates RFCs 3264, 5888, and 7941.
</t>
<!-- <t>
This specification updates RFC 3264, to also allow assigning a zero port value This specification updates RFC 3264, to also allow assigning a zero port value
to a "m=" section in cases where the media described by the "m=" section to an "m=" section in cases where the media described by the "m=" sectio n
is not disabled or rejected. is not disabled or rejected.
</t> </t>
<t> <t>
This specification updates RFC 5888, to also allow an SDP 'group' attrib This specification updates RFC 5888, to also allow an SDP 'group'
ute to attribute to contain an identification-tag that identifies an "m="
contain an identification-tag that identifies a "m=" section with the po section with the port set to zero.
rt set to zero.
</t> </t>
<t> <t>
This specification defines a new RTP Control Protocol This specification defines a new RTP Control Protocol
(RTCP) source description (SDES) item and a new RTP header (RTCP) Source Description (SDES) item and a new RTP header
extension that can be used to correlate bundled RTP/RTCP packets extension that can be used to correlate bundled RTP/RTCP packets
with their appropriate "m=" section. with their appropriate "m=" section.
</t> </t>
<t> <t>
This specification updates RFC 7941, by adding an exception, This specification updates RFC 7941 by adding an exception, for the
for the MID RTP header extension, to the requirement regarding protectio Media Identification (MID) RTP header extension, to the requirement
n regarding protection of an SDES RTP header extension carrying an SDES
of an SDES RTP header extension carrying an SDES item for the MID RTP item for the MID RTP header extension.
header extension. </t>-->
</t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section toc="default" numbered="true">
<section title="Introduction" toc="default"> <name>Introduction</name>
<section title="Background" toc="default"> <section toc="default" numbered="true">
<t> <name>Background</name>
When the SDP offer/answer mechanism <xref format="default" pageno="false <t>
" target="RFC3264"/> When the SDP offer/answer mechanism <xref format="default" target="RFC32
64"/>
is used to negotiate the establishment of multimedia communication sessi ons, if separate is used to negotiate the establishment of multimedia communication sessi ons, if separate
transports (5-tuples) are negotiated for each individual media stream, e ach transport consumes transports (5-tuples) are negotiated for each individual media stream, e ach transport consumes
additional resources (especially when Interactive Connectivity Establish ment (ICE) additional resources (especially when Interactive Connectivity Establish ment (ICE)
<xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/> is used). <xref format="default" target="RFC8445"/> is used).
For this reason, it is attractive to use a single transport for multiple media streams. For this reason, it is attractive to use a single transport for multiple media streams.
</t> </t>
</section> </section>
<section title="BUNDLE Mechanism" toc="default"> <section toc="default" numbered="true">
<t> <name>BUNDLE Mechanism</name>
<t>
This specification defines a way to use a single transport (BUNDLE trans port) This specification defines a way to use a single transport (BUNDLE trans port)
for sending and receiving media (bundled media) described by multiple SD P media descriptions for sending and receiving media (bundled media) described by multiple SD P media descriptions
("m=" sections). The address:port combination used by an endpoint for se nding and receiving ("m=" sections). The address:port combination used by an endpoint for se nding and receiving
bundled media is referred to as the BUNDLE address:port. The set of SDP attributes that are bundled media is referred to as the BUNDLE address:port. The set of SDP attributes that are
applied to each "m=" section within a BUNDLE group is referred to as BUN DLE attributes. applied to each "m=" section within a BUNDLE group is referred to as BUN DLE attributes.
The same BUNDLE transport is used for sending and receiving bundled medi a, which The same BUNDLE transport is used for sending and receiving bundled medi a, which
means that the symmetric Real-time Transport Protocol (RTP) mechanism <x means that the symmetric Real-time Transport Protocol (RTP) mechanism <x
ref format="default" ref format="default" target="RFC4961"/> is always used for RTP-based bundled med
pageno="false" target="RFC4961"/> is always used for RTP-based bundled me ia.
dia. </t>
</t>
<t> <t>
This specification defines a new SDP Grouping Framework <xref format="de This specification defines a new SDP Grouping Framework <xref format="de
fault" pageno="false" fault" target="RFC5888"/> extension called 'BUNDLE'. The extension can be used w
target="RFC5888"/> extension called 'BUNDLE'. The extension can be used ith the Session Description
with the Session Description Protocol (SDP) Offer/Answer mechanism <xref format="default" target="RFC
Protocol (SDP) Offer/Answer mechanism <xref format="default" pageno="fal 3264"/>
se" target="RFC3264"/>
to negotiate which "m=" sections will become part of a BUNDLE group. In addition, the offerer and to negotiate which "m=" sections will become part of a BUNDLE group. In addition, the offerer and
answerer <xref format="default" pageno="false" target="RFC3264"/> use th e BUNDLE extension to negotiate answerer <xref format="default" target="RFC3264"/> use the BUNDLE extens ion to negotiate
the BUNDLE addresses:ports (offerer BUNDLE address:port and answerer BUN DLE address:port) and the the BUNDLE addresses:ports (offerer BUNDLE address:port and answerer BUN DLE address:port) and the
set of BUNDLE attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) that will be applied to set of BUNDLE attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) that will be applied to
each "m=" section within the BUNDLE group. each "m=" section within the BUNDLE group.
</t> </t>
<t>
<t>
The use of a BUNDLE transport allows the usage of a single set of The use of a BUNDLE transport allows the usage of a single set of
Interactive Connectivity Establishment (ICE) <xref format="default" page ICE <xref format="default" target="RFC8445"/> candidates for the whole B
no="false" UNDLE group.
target="I-D.ietf-ice-rfc5245bis"/> candidates for the whole BUNDLE group </t>
. <t>
</t> A given BUNDLE address:port <bcp14>MUST</bcp14> only be associated with
<t> a single BUNDLE group. If an SDP offer
A given BUNDLE address:port MUST only be associated with a single BUNDLE
group. If an SDP offer
or answer contains multiple BUNDLE groups, the procedures in this specif ication apply to each or answer contains multiple BUNDLE groups, the procedures in this specif ication apply to each
group independently. All RTP-based bundled media associated with a given BUNDLE group belong to a single group independently. All RTP-based bundled media associated with a given BUNDLE group belong to a single
RTP session <xref format="default" pageno="false" target="RFC3550"/>. RTP session <xref format="default" target="RFC3550"/>.
</t>
<t>
The BUNDLE extension is backward compatible. Endpoints that do not suppo
rt the extension
are expected to generate offers and answers without an SDP 'group:BUNDLE
' attribute, and
are expected to assign a unique address:port to each "m=" section within
an offer and answer, according
to the procedures in <xref format="default" pageno="false" target="RFC45
66"/> and
<xref format="default" pageno="false" target="RFC3264"/>.
</t>
</section>
<section title="Protocol Extensions" toc="default">
<t>
In addition to defining the new SDP Grouping Framework extension, this s
pecification defines
the following protocol extensions and RFC updates:
<list style="symbols">
<t>
The specification defines a new SDP attribute, 'bundle-only', which ca
n be used to
request that a specific "m=" section (and the associated media) is use
d only used if kept
within a BUNDLE group.
</t> </t>
<t> <t>
The specification updates RFC 3264 <xref format="default" pageno="fals The BUNDLE extension is backward compatible. Endpoints that do not suppo
e" rt the extension
target="RFC3264"/>, to also allow assigning a zero port value to a "m= are expected to generate offers and answers without an SDP 'group:BUNDLE
" section ' attribute and
in cases where the media described by the "m=" section is not disabled assign a unique address:port to each "m=" section within an offer and an
or rejected. swer, according
to the procedures in
<xref format="default" target="RFC3264"/> and <xref format="default" targ
et="RFC4566"/>.
</t> </t>
</section>
<section toc="default" numbered="true">
<name>Protocol Extensions</name>
<t> <t>
The specification defines a new RTP Control Protocol (RTCP) <xref form In addition to defining the new SDP Grouping Framework extension, this s
at="default" pecification defines
pageno="false" target="RFC3550"/> source description (SDES) item, 'MID the following protocol extensions and RFC updates. This specification:
', and a new RTP SDES header
extension that can be used to associate RTP streams with "m=" sections
.
</t> </t>
<t> <ul spacing="normal">
The specification updates <xref format="default" pageno="false" target <li>
="RFC7941"/>, by adding an exception, defines a new SDP attribute, 'bundle-only', which can be used to
request that a specific "m=" section (and the associated media) be use
d only if kept
within a BUNDLE group.
</li>
<li>
updates RFC 3264 <xref format="default" target="RFC3264"/>, to also al
low assigning a zero port value to an "m=" section
in cases where the media described by the "m=" section is not disabled
or rejected.
</li>
<li>
defines a new RTCP <xref format="default" target="RFC3550"/> SDES item
, 'MID', and a new RTP SDES header
extension that can be used to associate RTP streams with "m=" sections
.
</li>
<li>
updates <xref format="default" target="RFC7941"/> by adding an excepti
on,
for the MID RTP header extension, to the requirement regarding protect ion for the MID RTP header extension, to the requirement regarding protect ion
of an SDES RTP header extension carrying an SDES item for the MID RTP of an SDES RTP header extension carrying an SDES item for the MID RTP
header extension. header extension.
</t> </li>
</list> </ul>
</t> </section>
</section> </section>
</section> <section anchor="sec-term" toc="default" numbered="true">
<name>Terminology</name>
<section anchor="sec-term" title="Terminology" toc="default"> <ul empty="true">
<t> <li>
<list style="symbols"> <dl newline="false" spacing="normal">
<t> <dt>"m=" section:</dt><dd> SDP bodies contain one or more media descriptio
"m=" section: SDP bodies contain one or more media descriptions, referred ns, referred to
to as "m=" sections. Each "m=" section is represented by an SDP "m=" line and
as "m=" sections. Each "m=" section is represented by an SDP "m=" line, an zero or more
d zero or more
SDP attributes associated with the "m=" line. A local address:port combina tion is SDP attributes associated with the "m=" line. A local address:port combina tion is
assigned to each "m=" section. assigned to each "m=" section.</dd>
</t>
<t> <dt>5-tuple:</dt><dd>A collection of the following values: source address,
5-tuple: A collection of the following values: source address, source source
port, destination address, destination port, and transport-layer port, destination address, destination port, and transport-layer
protocol. protocol.</dd>
</t>
<t> <dt>Unique address:port:</dt><dd>An address:port combination that is assig
Unique address:port: An address:port combination that is assigned to ned to
only one "m=" section in an offer or answer. only one "m=" section in an offer or answer.</dd>
</t>
<t> <dt>Offerer BUNDLE-tag:</dt><dd>The first identification-tag in a given
Offerer BUNDLE-tag: The first identification-tag in a given SDP 'group:BUNDLE' attribute identification-tag list in an offer.</dd>
SDP 'group:BUNDLE' attribute identification-tag list in an offer.
</t> <dt>Answerer BUNDLE-tag:</dt><dd>The first identification-tag in a given
<t> SDP 'group:BUNDLE' attribute identification-tag list in an answer.</dd>
Answerer BUNDLE-tag: The first identification-tag in a given
SDP 'group:BUNDLE' attribute identification-tag list in an answer. <dt> Suggested offerer-tagged "m=" section:</dt><dd> The bundled "m=" secti
</t> on identified by the offerer BUNDLE-tag in an initial BUNDLE offer,
<t> before a BUNDLE group has been negotiated.</dd>
Suggested offerer tagged "m=" section: The bundled "m=" section identified
by the offerer BUNDLE-tag in an initial BUNDLE offer, <dt>Offerer-tagged "m=" section:</dt><dd>The bundled "m=" section identifi
before a BUNDLE group has been negotiated. ed by the offerer BUNDLE-tag in a subsequent offer.
</t> The "m=" section contains characteristics (offerer BUNDLE address:port and
<t> offerer BUNDLE attributes) that are applied to
Offerer tagged "m=" section: The bundled "m=" section identified by the of each "m=" section within the BUNDLE group.</dd>
ferer BUNDLE-tag in a subsequent offer.
The "m=" section contains characteristics (offerer BUNDLE address:port and <dt>Answerer-tagged "m=" section:</dt><dd>The bundled "m=" section identif
offerer BUNDLE attributes) applied to ied by the answerer BUNDLE-tag in an answer
each "m=" section within the BUNDLE group.
</t>
<t>
Answerer tagged "m=" section: The bundled "m=" section identified by the a
nswerer BUNDLE-tag in an answer
(initial BUNDLE answer or subsequent). The "m=" section contains character istics (answerer BUNDLE address:port and answerer BUNDLE attributes) (initial BUNDLE answer or subsequent). The "m=" section contains character istics (answerer BUNDLE address:port and answerer BUNDLE attributes)
applied to each "m=" section within the BUNDLE group. that are applied to each "m=" section within the BUNDLE group.</dd>
</t>
<t> <dt>BUNDLE address:port:</dt><dd>An address:port combination that an endpo
BUNDLE address:port: An address:port combination that an endpoint uses for int uses for sending and receiving
sending and receiving bundled media.</dd>
bundled media.
</t> <dt>Offerer BUNDLE address:port:</dt><dd>The address:port combination used
<t> by the offerer
Offerer BUNDLE address:port: the address:port combination used by the offe for sending and receiving media.</dd>
rer
for sending and receiving media. <dt>Answerer BUNDLE address:port:</dt><dd>The address:port combination used
</t> by the answerer
<t> for sending and receiving media.</dd>
Answerer BUNDLE address:port: the address:port combination used by the ans
werer <dt>BUNDLE attributes:</dt><dd> IDENTICAL and TRANSPORT multiplexing catego
for sending and receiving media. ry SDP
</t>
<t>
BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP
attributes. Once a BUNDLE group has been created, the attribute values app ly attributes. Once a BUNDLE group has been created, the attribute values app ly
to each bundled "m=" section within the BUNDLE group. to each bundled "m=" section within the BUNDLE group.</dd>
</t>
<t> <dt>Offerer BUNDLE attributes:</dt><dd>IDENTICAL and TRANSPORT multiplexin
Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category S g category SDP
DP attributes included in the offerer-tagged "m=" section. </dd>
attributes included in the offerer tagged "m=" section.
</t> <dt>Answerer BUNDLE attributes:</dt><dd>IDENTICAL and TRANSPORT multiplexi
<t> ng category SDP
Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category attributes included in the answerer-tagged "m=" section.</dd>
SDP
attributes included in the answerer tagged "m=" section. <dt>BUNDLE transport:</dt><dd>The transport (5-tuple) used by all media de
</t> scribed by the
<t> "m=" sections within a BUNDLE group.</dd>
BUNDLE transport: The transport (5-tuple) used by all media described by t
he <dt>BUNDLE group:</dt><dd>A set of bundled "m=" sections, created using an
"m=" sections within a BUNDLE group. SDP Offer/Answer
</t> exchange, that uses a single BUNDLE transport, and a single set of BUNDLE
<t> attributes,
BUNDLE group: A set of bundled "m=" sections, created using an SDP Offer/A
nswer
exchange, which uses a single BUNDLE transport, and a single set of BUNDLE
attributes,
for sending and receiving all media (bundled media) described by the set o f "m=" sections. for sending and receiving all media (bundled media) described by the set o f "m=" sections.
The same BUNDLE transport is used for sending and receiving bundled media. The same BUNDLE transport is used for sending and receiving bundled media.
</t> </dd>
<t>
Bundled "m=" section: An "m=" section, whose identification-tag <dt>Bundled "m=" section:</dt><dd>An "m=" section, whose identification-tag
is placed in an SDP 'group:BUNDLE' attribute identification-tag list is placed in an SDP 'group:BUNDLE' attribute identification-tag list
in an offer or answer. in an offer or answer.</dd>
</t>
<t>
Bundle-only "m=" section: A bundled "m=" section that contains an
SDP 'bundle-only' attribute.
</t>
<t>
Bundled media: All media associated with a given BUNDLE group.
</t>
<t>
Initial BUNDLE offer: The first offer, within an SDP session (e.g. a SIP d
ialog
when the Session Initiation Protocol (SIP) <xref format="default"
pageno="false" target="RFC3261" /> is used to carry SDP), in which
the offerer indicates that it wants to negotiate a given BUNDLE group.
</t>
<t>
Initial BUNDLE answer: The answer to an initial BUNDLE offer in which the
offerer indicates that it wants to negotiate
a BUNDLE group, and where the answerer accepts the creation of the BUNDLE
group. The BUNDLE group is
created once the answerer sends the initial BUNDLE answer.
</t>
<t>
Subsequent offer: An offer which contains a BUNDLE group that
has been created as part of a previous offer/answer exchange.
</t>
<t>
Subsequent answer: An answer to a subsequent offer.
</t>
<t>
Identification-tag: A unique token value that is used to identify an
"m=" section. The SDP 'mid' attribute <xref format="default" pageno="false
"
target="RFC5888" /> in an "m=" section carries the unique identification-t
ag
assigned to that "m=" section. The session-level SDP 'group' attribute
<xref format="default" pageno="false" target="RFC5888" /> carries a list o
f
identification-tags, identifying the "m=" sections associated with that
particular 'group' attribute.
</t>
</list>
</t>
</section>
<section title="Conventions" toc="default"> <dt>Bundle-only "m=" section:</dt><dd>A bundled "m=" section that contains
<t> an
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL SDP 'bundle-only' attribute.</dd>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref format="default" pageno="false" target="RFC2119"
/>
<xref format="default" pageno="false" target="RFC8174" /> when,
and only when, they appear in all capitals, as shown here.
</t>
</section>
<section title="Applicability Statement" toc="default"> <dt>Bundled media:</dt><dd>All media associated with a given BUNDLE group.<
<t> /dd>
The mechanism in this specification only applies to the Session
Description Protocol (SDP) <xref format="default" pageno="false"
target="RFC4566"/>, when used together with the SDP offer/answer
mechanism <xref format="default" pageno="false" target="RFC3264"/>.
Declarative usage of SDP is out of scope of this document, and is
thus undefined.
</t>
</section>
<section title="SDP Grouping Framework BUNDLE Extension" anchor="sec-group" to <dt>Initial BUNDLE offer:</dt><dd>The first offer, within an SDP session (
c="default"> e.g., a SIP dialog
<t> when SIP <xref format="default" target="RFC3261"/> is used to carry SDP),
This section defines a new SDP Grouping Framework <xref format="default" in which
pageno="false" the offerer indicates that it wants to negotiate a given BUNDLE group.</dd
target="RFC5888"/> extension, 'BUNDLE'. The BUNDLE extension can be used >
with the SDP
<dt>Initial BUNDLE answer:</dt><dd>The answer to an initial BUNDLE offer i
n which the offerer indicates that it wants to negotiate
a BUNDLE group, and the answerer accepts the creation of the BUNDLE group.
The BUNDLE group is
created once the answerer sends the initial BUNDLE answer.</dd>
<dt>Subsequent offer:</dt><dd>An offer that contains a BUNDLE group that
has been created as part of a previous offer/answer exchange.</dd>
<dt>Subsequent answer:</dt><dd>An answer to a subsequent offer.</dd>
<dt>Identification-tag:</dt><dd>A unique token value that is used to ident
ify an
"m=" section. The SDP 'mid' attribute <xref format="default" target="RFC58
88"/> in an "m=" section carries the unique identification-tag
assigned to that "m=" section. The session-level SDP 'group' attribute
<xref format="default" target="RFC5888"/> carries a list of
identification-tags, identifying the "m=" sections associated with that
particular 'group' attribute.</dd>
</dl>
</li>
</ul>
</section>
<section toc="default" numbered="true">
<name>Conventions</name>
<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.
</t>
</section>
<section toc="default" numbered="true">
<name>Applicability Statement</name>
<t>
The mechanism in this specification only applies to SDP <xref format="defa
ult" target="RFC4566"/>, when used together with the SDP offer/answer
mechanism <xref format="default" target="RFC3264"/>.
Declarative usage of SDP is out of scope of this document and is
thus undefined.
</t>
</section>
<section anchor="sec-group" toc="default" numbered="true">
<name>SDP Grouping Framework BUNDLE Extension</name>
<t>
This section defines a new SDP Grouping Framework <xref format="default"
target="RFC5888"/> extension, 'BUNDLE'. The BUNDLE extension can be used with th
e SDP
Offer/Answer mechanism to negotiate a set of "m=" sections that will beco me part of a BUNDLE Offer/Answer mechanism to negotiate a set of "m=" sections that will beco me part of a BUNDLE
group. Within a BUNDLE group, each "m=" section uses a BUNDLE transport f or sending and group. Within a BUNDLE group, each "m=" section uses a BUNDLE transport f or sending and
receiving bundled media. Each endpoint uses a single address:port combina tion for sending and receiving bundled media. Each endpoint uses a single address:port combina tion for sending and
receiving the bundled media. receiving the bundled media.
</t> </t>
<t> <t>
The BUNDLE extension is indicated using an SDP 'group' attribute with a s emantics value The BUNDLE extension is indicated using an SDP 'group' attribute with a s emantics value
<xref format="default" pageno="false" target="RFC5888"/> of "BUNDLE". <xref format="default" target="RFC5888"/> of "BUNDLE".
An identification-tag is assigned to each bundled An identification-tag is assigned to each bundled
"m=" section, and each identification-tag is listed in the SDP 'group:BUN DLE' "m=" section, and each identification-tag is listed in the SDP 'group:BUN DLE'
attribute identification-tag list. Each "m=" section whose identification -tag attribute identification-tag list. Each "m=" section whose identification -tag
is listed in the identification-tag list is associated with a given is listed in the identification-tag list is associated with a given
BUNDLE group. BUNDLE group.
</t> </t>
<t> <t>
SDP bodies can contain multiple BUNDLE groups. Any given bundled "m=" SDP bodies can contain multiple BUNDLE groups. Any given bundled "m="
section MUST NOT be associated with more than one BUNDLE group at any giv en section <bcp14>MUST NOT</bcp14> be associated with more than one BUNDLE g roup at any given
time. time.
</t> </t>
<t> <t>
NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' att ribute NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' att ribute
identification-tag list does not have to be the same as the order in whic h identification-tag list does not have to be the same as the order in whic h
the "m=" sections occur in the SDP. the "m=" sections occur in the SDP.
</t> </t>
<t> <t>
The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'g The multiplexing category <xref target="RFC8859"/> for the 'group:BUNDLE'
roup:BUNDLE'
attribute is 'NORMAL'. attribute is 'NORMAL'.
</t> </t>
<t> <t>
<xref target="sec-sdp-oa" pageno="false" format="default"/> defines the <xref target="sec-sdp-oa" format="default"/> defines the
detailed SDP Offer/Answer procedures for the BUNDLE extension. detailed SDP Offer/Answer procedures for the BUNDLE extension.
</t> </t>
</section> </section>
<section anchor="sec-bundle-only" toc="default" numbered="true">
<section anchor="sec-bundle-only" title="SDP 'bundle-only' Attribute" toc="def <name>SDP 'bundle-only' Attribute</name>
ault"> <t>
<t> This section defines a new SDP media-level attribute <xref target="RFC4566
This section defines a new SDP media-level attribute <xref target="RFC4566 " format="default"/>, 'bundle-only'. 'bundle-only' is a property attribute
" pageno="false" <xref target="RFC4566" format="default"/> and hence has no value.
format="default"/>, 'bundle-only'. 'bundle-only' is a property attribute </t>
<xref target="RFC4566" pageno="false" format="default"/>, and hence has no <t>
value.
</t>
<t>
In order to ensure that an answerer that does not support the BUNDLE exten sion always In order to ensure that an answerer that does not support the BUNDLE exten sion always
rejects a bundled "m=" section in an offer, the offerer can assign a zero port value to the "m=" rejects a bundled "m=" section in an offer, the offerer can assign a zero port value to the "m="
section. According to <xref target="RFC3264" pageno="false" format="defaul t"/> an answerer section. According to <xref target="RFC3264" format="default"/>, an answer er
will reject such an "m=" section. will reject such an "m=" section.
By including an SDP 'bundle-only' attribute in a bundled "m=" section, the offerer can By including an SDP 'bundle-only' attribute in a bundled "m=" section, the offerer can
request that the answerer accepts the "m=" section only if the answerer su pports the BUNDLE request that the answerer accepts the "m=" section only if the answerer su pports the BUNDLE
extension, and if the answerer keeps the "m=" section within the associate extension and if the answerer keeps the "m=" section within the associated
d BUNDLE group. BUNDLE group.
</t> </t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Name: bundle-only
Value: N/A <ul empty="true">
<li>
<dl newline="false" spacing="normal">
<dt>Name:</dt><dd>bundle-only</dd>
Usage Level: media <dt>Value:</dt><dd>N/A</dd>
Charset Dependent: no <dt>Usage Level:</dt><dd>media</dd>
Example: <dt>Charset Dependent:</dt><dd>no</dd>
a=bundle-only <dt>Example:</dt><dd>a=bundle-only</dd></dl>
</li></ul>
]]></artwork> <t>
</figure> Once the offerer-tagged "m=" section and the answerer-tagged "m=" section
<t> have been selected,
Once the offerer tagged "m=" section and the answerer tagged "m=" section
have been selected,
an offerer and answerer will include an SDP 'bundle-only' attribute in, an d assign a zero an offerer and answerer will include an SDP 'bundle-only' attribute in, an d assign a zero
port value to, every other bundled "m=" section. port value to, every other bundled "m=" section.
</t> </t>
<t> <t>
The usage of the 'bundle-only' attribute is only defined for a bundled "m= " section with The usage of the 'bundle-only' attribute is only defined for a bundled "m= " section with
a zero port value. Other usage is unspecified. a zero port value. Other usage is unspecified.
</t> </t>
<t> <t>
<xref target="sec-sdp-oa" pageno="false" format="default"/> defines the de <xref target="sec-sdp-oa" format="default"/> defines the detailed SDP
tailed SDP
Offer/Answer procedures for the 'bundle-only' attribute. Offer/Answer procedures for the 'bundle-only' attribute.
</t> </t>
</section> </section>
<section anchor="sec-sdp-oa" toc="default" numbered="true">
<section title="SDP Offer/Answer Procedures" anchor="sec-sdp-oa" toc="default" <name>SDP Offer/Answer Procedures</name>
>
<t> <t>
This section describes the SDP Offer/Answer <xref format="default" This section describes the SDP Offer/Answer <xref format="default" targe
pageno="false" target="RFC3264"/> procedures for: t="RFC3264"/> procedures for:
<list style="symbols"> </t>
<t> <ul spacing="normal">
Negotiating a BUNDLE group; and <li>
</t> Negotiating a BUNDLE group;
<t> </li>
Suggesting and selecting the tagged "m=" sections (offerer tagged "m <li>
=" section and answerer tagged "m=" section); and Suggesting and selecting the tagged "m=" sections (offerer-tagged "m
</t> =" section and answerer-tagged "m=" section);
<t> </li>
Adding an "m=" section to a BUNDLE group; and <li>
</t> Adding an "m=" section to a BUNDLE group;
<t> </li>
<li>
Moving an "m=" section out of a BUNDLE group; and Moving an "m=" section out of a BUNDLE group; and
</t> </li>
<t> <li>
Disabling an "m=" section within a BUNDLE group. Disabling an "m=" section within a BUNDLE group.
</t> </li>
</list> </ul>
</t>
<t> <t>
The generic rules and procedures defined in <xref format="default" pagen The generic rules and procedures defined in <xref format="default" targe
o="false" t="RFC3264"/> and <xref format="default" target="RFC5888"/>
target="RFC3264"/> and <xref format="default" pageno="false" target="RFC
5888"/>
also apply to the BUNDLE extension. For example, if an offer is rejected also apply to the BUNDLE extension. For example, if an offer is rejected
by the answerer, the previously negotiated addresses:ports, SDP paramete rs and characteristics by the answerer, the previously negotiated addresses:ports, SDP paramete rs, and characteristics
(including those associated with a BUNDLE group) apply. Hence, if an off erer (including those associated with a BUNDLE group) apply. Hence, if an off erer
generates an offer in order to negotiate a BUNDLE group, generates an offer in order to negotiate a BUNDLE group,
and the answerer rejects the offer, the BUNDLE group is not created. and the answerer rejects the offer, the BUNDLE group is not created.
</t> </t>
<t> <t>
The procedures in this section are independent of the media type or The procedures in this section are independent of the media type or
"m=" line proto value assigned to a bundled "m=" section. "m=" line proto value assigned to a bundled "m=" section. <xref format="
<xref format="default" pageno="false" target="sec-rtp"/> defines additio default" target="sec-bundle-only"/> defines
nal
considerations for RTP based media.
<xref format="default" pageno="false" target="sec-bundle-only"/> defines
additional considerations for the usage of the SDP 'bundle-only' attribu te. additional considerations for the usage of the SDP 'bundle-only' attribu te.
<xref format="default" pageno="false" target="sec-ice"/> defines additio <xref format="default" target="sec-rtp"/> defines additional
nal considerations for RTP-based media.
considerations for the usage of Interactive Connectivity Establishment (
ICE) <xref format="default" target="sec-ice"/> defines additional
<xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/> considerations for the usage of the ICE
mechanism. <xref format="default" target="RFC8445"/> mechanism.
</t> </t>
<t> <t>
Offers and answers can contain multiple BUNDLE groups. The procedures in this Offers and answers can contain multiple BUNDLE groups. The procedures in this
section apply independently to a given BUNDLE group. section apply independently to a given BUNDLE group.
</t> </t>
<section anchor="sec-sdp-cons" toc="default" numbered="true">
<section title="Generic SDP Considerations" anchor="sec-sdp-cons" toc="def <name>Generic SDP Considerations</name>
ault">
<t> <t>
This section describes generic restrictions associated with the usage of This section describes generic restrictions associated with the usage of
SDP parameters within a BUNDLE group. It also describes how to calcula te a SDP parameters within a BUNDLE group. It also describes how to calcula te a
value for the whole BUNDLE group, when parameter and attribute values have been assigned value for the whole BUNDLE group, when parameter and attribute values have been assigned
to each bundled "m=" section. to each bundled "m=" section.
</t> </t>
<section title="Connection Data (c=)" anchor="sec-sdp-cons-c" toc="defau <section anchor="sec-sdp-cons-c" toc="default" numbered="true">
lt"> <name>Connection Data ("c=")</name>
<t> <t>
The "c=" line nettype value <xref format="default" pageno="false" The "c=" line nettype value <xref format="default" target="RFC4566"/
target="RFC4566"/> associated with a bundled "m=" section MUST be 'I > associated with a bundled "m=" section <bcp14>MUST</bcp14> be 'IN'.
N'.
</t> </t>
<t> <t>
The "c=" line addrtype value <xref format="default" pageno="false" The "c=" line addrtype value <xref format="default" target="RFC4566"
target="RFC4566"/> associated with a bundled "m=" section MUST be 'I /> associated with a bundled "m=" section <bcp14>MUST</bcp14> be 'IP4' or
P4' or 'IP6'. The same value <bcp14>MUST</bcp14> be associated with each "m
'IP6'. The same value MUST be associated with each "m=" section. =" section.
</t> </t>
<t> <t>
NOTE: Extensions to this specification can specify usage of the BUND LE NOTE: Extensions to this specification can specify usage of the BUND LE
mechanism for other nettype and addrtype values than the ones listed above. mechanism for other nettype and addrtype values than the ones listed above.
</t> </t>
</section> </section>
<section title="Bandwidth (b=)" anchor="sec-sdp-cons-b" toc="default"> <section anchor="sec-sdp-cons-b" toc="default" numbered="true">
<name>Bandwidth ("b=")</name>
<t> <t>
An offerer and answerer MUST use the rules and restrictions defined An offerer and answerer <bcp14>MUST</bcp14> use the rules and restri
in <xref target="I-D.ietf-mmusic-sdp-mux-attributes" /> for ctions defined
associating the SDP bandwidth (b=) line with bundled "m=" sections. in <xref target="RFC8859" format="default"/> for
associating the SDP bandwidth ("b=") line with bundled "m=" sections
.
</t> </t>
</section> </section>
<section anchor="sec-sdp-oa-cat" title="Attributes (a=)" toc="default"> <section anchor="sec-sdp-oa-cat" toc="default" numbered="true">
<name>Attributes ("a=")</name>
<t> <t>
An offerer and answerer MUST include SDP attributes in every bundled "m=" section where applicable, An offerer and answerer <bcp14>MUST</bcp14> include SDP attributes i n every bundled "m=" section where applicable,
following the normal offer/answer procedures for each attribute, wit h the following exceptions: following the normal offer/answer procedures for each attribute, wit h the following exceptions:
<list style="symbols">
<t>
In the initial BUNDLE offer, the offerer MUST NOT include IDENTICA
L and TRANSPORT multiplexing category SDP
attributes (BUNDLE attributes) in bundle-only "m=" sections. The o
fferer MUST include
such attributes in all other bundled "m=" sections. In the initial
BUNDLE offer each bundled "m=" line can contain
a different set of BUNDLE attributes, and attribute values. Once t
he offerer tagged "m=" section has been
selected, the BUNDLE attributes contained in the offerer tagged "m
=" section will apply to each bundled "m="
section within the BUNDLE group.
</t>
<t>
In a subsequent offer, or in an answer (initial of subsequent), th
e offerer and answerer MUST include
IDENTICAL and TRANSPORT multiplexing category SDP attributes (BUND
LE attributes) only in the tagged "m=" section
(offerer tagged "m=" section or answerer tagged "m=" section). The
offerer and answerer MUST NOT
include such attributes in any other bundled "m=" section. The BUN
DLE attributes contained in the tagged "m=" section
will apply to each bundled "m=" section within the BUNDLE group.
</t>
<t>
In an offer (initial BUNDLE offer or subsequent), or in an answer
(initial BUNDLE answer or subsequent), the offerer and answerer MUST
include SDP attributes of other categories than IDENTICAL and TRAN
SPORT in each bundled "m=" section that
a given attribute applies to. Each bundled "m=" line can contain a
different set of such attributes, and
attribute values, as such attributes only apply to the given bundl
ed "m=" section in which they are included.
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
In the initial BUNDLE offer, the offerer <bcp14>MUST NOT</bcp14>
include IDENTICAL and TRANSPORT multiplexing category SDP
attributes (BUNDLE attributes) in bundle-only "m=" sections. The
offerer <bcp14>MUST</bcp14> include such attributes in all other
bundled "m=" sections. In the initial BUNDLE offer, each bundled
"m=" line can contain a different set of BUNDLE attributes and
attribute values. Once the offerer-tagged "m=" section has been
selected, the BUNDLE attributes contained in the offerer-tagged
"m=" section will apply to each bundled "m=" section within the
BUNDLE group.
</li>
<li>
In a subsequent offer, or in an answer (initial of subsequent),
the offerer and answerer <bcp14>MUST</bcp14> include IDENTICAL
and TRANSPORT multiplexing category SDP attributes (BUNDLE
attributes) only in the tagged "m=" section (offerer-tagged "m="
section or answerer-tagged "m=" section). The offerer and
answerer <bcp14>MUST NOT</bcp14> include such attributes in any
other bundled "m=" section. The BUNDLE attributes contained in
the tagged "m=" section will apply to each bundled "m=" section
within the BUNDLE group.
</li>
<li>
In an offer (initial BUNDLE offer or subsequent), or in an
answer (initial BUNDLE answer or subsequent), the offerer and
answerer <bcp14>MUST</bcp14> include SDP attributes from
categories other than IDENTICAL and TRANSPORT in each bundled
"m=" section that a given attribute applies to. Each bundled
"m=" line can contain a different set of such attributes, and
attribute values, as such attributes only apply to the given
bundled "m=" section in which they are included.
</li>
</ul>
<t> <t>
NOTE: A consequence of the rules above is that media-specific IDENTI NOTE: A consequence of the rules above is that media-specific
CAL and TRANSPORT multiplexing IDENTICAL and TRANSPORT multiplexing category SDP attributes that
category SDP attributes which are applicable only to some of the bun are applicable only to some of the bundled "m=" sections within
dled "m=" sections within the BUNDLE group might appear in the tagged "m=" section for which
the BUNDLE group might appear in the tagged "m=" section for which t they are not applicable. For instance, the tagged "m=" section
hey are not applicable. For instance, might contain an SDP 'rtcp-mux' attribute even if the tagged "m="
the tagged "m=" section might contain an SDP 'rtcp-mux' attribute ev section does not describe RTP-based media (but another bundled
en if the tagged "m=" section does not describe "m=" section within the BUNDLE group does describe RTP-based
RTP-based media (but another bundled "m=" section within the BUNDLE media).
group does describe RTP-based media).
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec-sdp-oa-ino" title="Generating the Initial SDP Offer" to <section anchor="sec-sdp-oa-ino" toc="default" numbered="true">
c="default"> <name>Generating the Initial SDP Offer</name>
<t> <t>
The procedures in this section apply to the first offer, within an SDP The procedures in this section apply to the first offer, within an SDP
session (e.g. a SIP session (e.g., a SIP
dialog when the Session Initiation Protocol (SIP) [RFC3261] is used to dialog when SIP <xref target="RFC3261"/> is used to carry SDP), in whi
carry SDP), in which the ch the
offerer indicates that it wants to negotiate a given BUNDLE group. Thi s could occur in the offerer indicates that it wants to negotiate a given BUNDLE group. Thi s could occur in the
initial offer, or in a subsequent offer, of the SDP session. initial offer, or in a subsequent offer, of the SDP session.
</t> </t>
<t> <t>
When an offerer generates an initial BUNDLE offer, in order to negotia te a When an offerer generates an initial BUNDLE offer, in order to negotia te a
BUNDLE group, it MUST: BUNDLE group, it <bcp14>MUST</bcp14>:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
Assign a unique address:port to each bundled "m=" section, Assign a unique address:port to each bundled "m=" section,
following the procedures in <xref target="RFC3264" pageno="false" following the procedures in <xref target="RFC3264" format="default
format="default"/>, excluding any bundle-only "m=" sections (see b "/>, excluding any bundle-only "m=" sections (see below);
elow); and </li>
</t> <li>
<t> Pick a bundled "m=" section as the suggested offerer-tagged "m=" (
Pick a bundled "m=" section as the suggested offerer tagged "m=" s <xref target="sec-sdp-oa-ino-req" format="default"/>);
ection [<xref target="sec-sdp-oa-ino-req" </li>
pageno="false" format="default"/>]; and <li>
</t>
<t>
Include SDP attributes in the bundled "m=" sections following the rules Include SDP attributes in the bundled "m=" sections following the rules
in [<xref target="sec-sdp-oa-cat" pageno="false" format="default"/ in <xref target="sec-sdp-oa-cat" format="default"/>;
>]; and </li>
</t> <li>
<t>
Include an SDP 'group:BUNDLE' attribute in the offer; and Include an SDP 'group:BUNDLE' attribute in the offer; and
</t> </li>
<t> <li>
Place the identification-tag of each bundled "m=" section in the Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag
indicates the suggested offerer tagged "m=" section. indicates the suggested offerer-tagged "m=" section.
</t> </li>
</list> </ul>
</t>
<t> <t>
NOTE: When the offerer assigns unique addresses:ports to multiple bund led "m=" sections, the offerer needs to be prepared NOTE: When the offerer assigns unique addresses:ports to multiple bund led "m=" sections, the offerer needs to be prepared
to receive bundled media on each unique address:port, until it receive s the associated answer and finds out which to receive bundled media on each unique address:port, until it receive s the associated answer and finds out which
bundled "m=" section (and associated address:port combination) the ans werer has selected as the offerer tagged "m=" section. bundled "m=" section (and associated address:port combination) the ans werer has selected as the offerer-tagged "m=" section.
</t> </t>
<t> <t>
If the offerer wants to request that the answerer accepts a given bund led "m=" section only if If the offerer wants to request that the answerer accepts a given bund led "m=" section only if
the answerer keeps the "m=" section within the negotiated BUNDLE group the answerer keeps the "m=" section within the negotiated BUNDLE group
, the offerer MUST: , the offerer <bcp14>MUST</bcp14>:
<list style="symbols">
<t>
Include an SDP 'bundle-only' attribute [<xref target="sec-sdp-oa-i
no-req" pageno="false"
format="default"/>] in the "m=" section; and
</t>
<t>
Assign a zero port value to the "m=" section.
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
Include an SDP 'bundle-only' attribute (<xref target="sec-sdp-oa-i
no-req" format="default"/>) in the "m=" section, and
</li>
<li>
Assign a zero port value to the "m=" section.
</li>
</ul>
<t> <t>
NOTE: If the offerer assigns a zero port value to a bundled "m=" secti on, but does not include an NOTE: If the offerer assigns a zero port value to a bundled "m=" secti on, but does not include an
SDP 'bundle-only' attribute in the "m=" section, it is an indication t hat the offerer wants SDP 'bundle-only' attribute in the "m=" section, it is an indication t hat the offerer wants
to disable the "m=" section [<xref target="sec-sdp-oa-mod-dis" pageno= "false" format="default"/>]. to disable the "m=" section (<xref target="sec-sdp-oa-mod-dis" format= "default"/>).
</t> </t>
<t> <t>
[<xref target="sec-sdp-oa-ino-ex" pageno="false" format="default"/>] a nd [<xref target="sec-example-add" pageno="false" format="default"/>] show Sections <xref target="sec-sdp-oa-ino-ex" format="counter"/> and <xref target="sec-example-add" format="counter"/> show
an example of an initial BUNDLE offer. an example of an initial BUNDLE offer.
</t> </t>
<section title="Suggesting the Offerer tagged 'm=' section" anchor="sec-sd <section anchor="sec-sdp-oa-ino-req" toc="default" numbered="true">
p-oa-ino-req" toc="default"> <name>Suggesting the Offerer-Tagged 'm=' Section</name>
<t> <t>
In the initial BUNDLE offer, the bundled "m=" section indicated by the In the initial BUNDLE offer, the bundled "m=" section indicated by the
offerer BUNDLE-tag is the suggested offerer tagged "m=" section. offerer BUNDLE-tag is the suggested offerer-tagged "m=" section.
The address:port combination associated with the "m=" section will be used by the offerer for sending and receiving bundled The address:port combination associated with the "m=" section will be used by the offerer for sending and receiving bundled
media if the answerer selects the "m=" section as the offerer tagged " media if the answerer selects the "m=" section as the offerer-tagged "
m=" section [<xref target="sec-sdp-oa-ans-off" m=" section (<xref target="sec-sdp-oa-ans-off" format="default"/>). In addition,
pageno="false" format="default"/>]. In addition, if the answerer selec if the answerer selects the "m=" section as the offerer-tagged "m=" section,
ts the "m=" section as the offerer tagged "m=" section,
the BUNDLE attributes included in the "m=" section will be applied to each "m=" section within the negotiated BUNDLE group. the BUNDLE attributes included in the "m=" section will be applied to each "m=" section within the negotiated BUNDLE group.
</t> </t>
<t> <t>
The offerer MUST NOT suggest a bundle-only "m=" section as the offerer The offerer <bcp14>MUST NOT</bcp14> suggest a bundle-only "m=" section
tagged "m=" section. as the offerer-tagged "m=" section.
</t> </t>
<t> <t>
It is RECOMMENDED that the suggested offerer tagged "m=" section is a It is <bcp14>RECOMMENDED</bcp14> that the suggested offerer-tagged "m=
bundled "m=" section " section be a bundled "m=" section
that the offerer believes it is unlikely that the answerer will reject that the offerer believes is unlikely that the answerer will reject or
, or move out of the BUNDLE group. move out of the BUNDLE group.
How such assumption is made is outside the scope of this document. How such assumption is made is outside the scope of this document.
</t> </t>
</section> </section>
<section anchor="sec-sdp-oa-ino-ex" title="Example: Initial SDP Offer"> <section anchor="sec-sdp-oa-ino-ex" numbered="true" toc="default">
<t> <name>Example: Initial SDP Offer</name>
<t>
The example shows an initial BUNDLE offer. The offer includes two The example shows an initial BUNDLE offer. The offer includes two
"m=" sections in the offer, and suggests that both "m=" sections are i "m=" sections in the offer and suggests that both "m=" sections are in
ncluded in a BUNDLE group. cluded in a BUNDLE group.
The audio "m=" section is the suggested offerer tagged "m=" section, i The audio "m=" section is the suggested offerer-tagged "m=" section, i
ndicated by placing the ndicated by placing the
identification-tag associated with the "m=" section (offerer BUNDLE-ta g) first in the SDP group:BUNDLE identification-tag associated with the "m=" section (offerer BUNDLE-ta g) first in the SDP group:BUNDLE
attribute identification-id list. attribute identification-id list.
</t> </t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer <t keepWithNext="true">SDP Offer</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at line 639 skipping to change at line 632
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux a=rtcp-mux
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
]]></sourcecode>
]]></artwork> </section>
</figure>
</section> </section>
</section> <section anchor="sec-sdp-oa-ans" toc="default" numbered="true">
<name>Generating the SDP Answer</name>
<section anchor="sec-sdp-oa-ans" title="Generating the SDP Answer" toc="defa
ult">
<t> <t>
When an answerer generates an answer (initial BUNDLE answer or subsequ When an answerer generates an answer (initial BUNDLE answer or subsequ
ent) that contains a BUNDLE group the following general ent) that contains a BUNDLE group, the following general
SDP grouping framework restrictions, defined in <xref target="RFC5888" SDP Grouping Framework restrictions, defined in <xref target="RFC5888"
pageno="false" format="default"/>, also apply to the BUNDLE group:
format="default"/>, also apply to the BUNDLE group:
<list style="symbols">
<t>
The answerer is only allowed to include a BUNDLE group in an initi
al BUNDLE answer if the offerer requested
the BUNDLE group to be created in the corresponding initial BUNDLE
offer; and
</t>
<t>
The answerer is only allowed to include a BUNDLE group in a subseq
uent answer if the corresponding
subsequent offer contains a previously negotiated BUNDLE group; an
d
</t>
<t>
The answerer is only allowed to include a bundled "m=" section in
an answer if the "m=" section was
indicated as bundled in the corresponding offer; and
</t>
<t>
The answerer is only allowed to include a bundled "m=" section in
the same BUNDLE group as the bundled
"m=" line in the corresponding offer.
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
The answerer is only allowed to include a BUNDLE group in an
initial BUNDLE answer if the offerer requested the BUNDLE group
to be created in the corresponding initial BUNDLE offer;
</li>
<li>
The answerer is only allowed to include a BUNDLE group in a
subsequent answer if the corresponding subsequent offer contains
a previously negotiated BUNDLE group;
</li>
<li>
The answerer is only allowed to include a bundled "m=" section
in an answer if the "m=" section was indicated as bundled in the
corresponding offer; and
</li>
<li>
The answerer is only allowed to include a bundled "m=" section
in the same BUNDLE group as the bundled "m=" line in the
corresponding offer.
</li>
</ul>
<t> <t>
In addition, when an answerer generates an answer (initial BUNDLE answ In addition, when an answerer generates an answer (initial BUNDLE
er or subsequent) that contains a BUNDLE group, the answerer MUST: answer or subsequent) that contains a BUNDLE group, the answerer
<list style="symbols"> <bcp14>MUST</bcp14>:
<t> </t>
In case of an initial BUNDLE answer, select the offerer tagged "m= <ul spacing="normal">
" section using the procedures in <xref target="sec-sdp-oa-ans-off" <li>
pageno="false" format="default"/>. In case of a subsequent answer, In case of an initial BUNDLE answer, select the offerer-tagged
the offerer tagged "m=" section is indicated "m=" section using the procedures in <xref
in the corresponding subsequent offer, and MUST NOT be changed by target="sec-sdp-oa-ans-off" format="default"/>. In case of a
the answerer; and subsequent answer, the offerer-tagged "m=" section is indicated
</t> in the corresponding subsequent offer and <bcp14>MUST
<t> NOT</bcp14> be changed by the answerer;
Select the answerer tagged "m=" section [<xref target="sec-sdp-oa- </li>
ans-off" <li>
pageno="false" format="default"/>]; and Select the answerer-tagged "m=" section (<xref
</t> target="sec-sdp-oa-ans-off" format="default"/>);
<t> </li>
Assign the answerer BUNDLE address:port to the answerer tagged "m= <li>
" section; and Assign the answerer BUNDLE address:port to the answerer-tagged "m=
</t> " section;
<t> </li>
<li>
Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every
other bundled "m=" section within the BUNDLE group; and other bundled "m=" section within the BUNDLE group;
</t> </li>
<t> <li>
Include SDP attributes in the bundled "m=" sections following the rules Include SDP attributes in the bundled "m=" sections following the rules
in [<xref target="sec-sdp-oa-cat" pageno="false" format="default"/ in <xref target="sec-sdp-oa-cat" format="default"/>;
>]; and </li>
</t> <li>
<t>
Include an SDP 'group:BUNDLE' attribute in the answer; and Include an SDP 'group:BUNDLE' attribute in the answer; and
</t> </li>
<t> <li>
Place the identification-tag of each bundled "m=" section in the Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list. The answerer BUNDLE-tag SDP 'group:BUNDLE' attribute identification-tag list. The answerer BUNDLE-tag
indicates the answerer tagged "m=" section [<xref target="sec-sdp- indicates the answerer-tagged "m=" section (<xref target="sec-sdp-
oa-ans-off" oa-ans-off" format="default"/>).
pageno="false" format="default"/>]. </li>
</t> </ul>
</list>
</t>
<t> <t>
If the answerer does not want to keep an "m=" section within a BUNDLE If the answerer does not want to keep an "m=" section within a BUNDLE
group, it MUST: group, it <bcp14>MUST</bcp14>:
<list style="symbols">
<t>
Move the "m=" section out of the BUNDLE group [<xref target="sec-s
dp-oa-ans-mov"
pageno="false" format="default"/>]; or
</t>
<t>
Reject the "m=" section [<xref target="sec-sdp-oa-ans-rej" pageno=
"false"
format="default"/>].
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
Move the "m=" section out of the BUNDLE group (<xref target="sec-s
dp-oa-ans-mov" format="default"/>); or
</li>
<li>
Reject the "m=" section (<xref target="sec-sdp-oa-ans-rej" format=
"default"/>).
</li>
</ul>
<t> <t>
The answerer can modify the answerer BUNDLE address:port, add and remo ve SDP attributes, or modify The answerer can modify the answerer BUNDLE address:port, add and remo ve SDP attributes, or modify
SDP attribute values, in a subsequent answer. Changes to the answerer BUNDLE address:port SDP attribute values in a subsequent answer. Changes to the answerer B UNDLE address:port
and the answerer BUNDLE attributes will be applied to each bundled "m= " section within the BUNDLE group. and the answerer BUNDLE attributes will be applied to each bundled "m= " section within the BUNDLE group.
</t> </t>
<t> <t>
NOTE: If a bundled "m=" section in an offer contains a zero port value , but the "m=" section NOTE: If a bundled "m=" section in an offer contains a zero port value , but the "m=" section
does not contain an SDP 'bundle-only' attribute, it is an indication t hat the offerer wants does not contain an SDP 'bundle-only' attribute, it is an indication t hat the offerer wants
to disable the "m=" section [<xref target="sec-sdp-oa-mod-dis" pageno= "false" format="default"/>]. to disable the "m=" section (<xref target="sec-sdp-oa-mod-dis" format= "default"/>).
</t> </t>
<section anchor="sec-sdp-oa-ans-off" toc="default" numbered="true">
<section title="Answerer Selection of tagged 'm=' sections" anchor="sec-sd <name>Answerer Selection of Tagged 'm=' Sections</name>
p-oa-ans-off" toc="default"> <t>
<t> When selecting the offerer-tagged "m=" section, the answerer <bcp14>MU
When the answerer selects the offerer tagged "m=" section, it first ch ST</bcp14>
ecks the suggested first check whether the "m=" section fulfils the following criteria
offerer tagged "m=" section [<xref target="sec-sdp-oa-ino-req" pageno= <xref target="sec-sdp-oa-ino-req" format="default"/>:
"false" format="default"/>]. </t>
The answerer MUST check whether the "m=" section fulfils the following <ul spacing="normal">
criteria: <li>
<list style="symbols">
<t>
The answerer will not move the "m=" section out of the BUNDLE grou p The answerer will not move the "m=" section out of the BUNDLE grou p
[<xref target="sec-sdp-oa-ans-mov" pageno="false" format="default" (<xref target="sec-sdp-oa-ans-mov" format="default"/>);
/>]; and </li>
</t> <li>
<t> The answerer will not reject the "m=" section (<xref target="sec-s
The answerer will not reject the "m=" section [<xref target="sec-s dp-oa-ans-rej" format="default"/>); and
dp-oa-ans-rej" </li>
pageno="false" format="default"/>]; and <li>
</t>
<t>
The "m=" section does not contain a zero port value. The "m=" section does not contain a zero port value.
</t> </li>
</list> </ul>
</t> <t>
<t> If all of the criteria above are fulfilled, the answerer <bcp14>MUST</
If all of the criteria above are fulfilled, the answerer MUST select bcp14> select
the "m=" section as the offerer tagged "m=" section, and MUST also mar the "m=" section as the offerer-tagged "m=" section and <bcp14>MUST</b
k cp14> also mark
the corresponding "m=" section in the answer as the answerer tagged "m the corresponding "m=" section in the answer as the answerer-tagged "m
=" section. =" section.
In the answer the answerer BUNDLE-tag indicates the answerer tagged "m In the answer, the answerer BUNDLE-tag indicates the answerer-tagged "
=" section. m=" section.
</t> </t>
<t> <t>
If one or more of the criteria are not fulfilled, the answerer MUST pi If one or more of the criteria are not fulfilled, the answerer <bcp14>
ck the next MUST</bcp14> pick the next
identification-tag in the identification-tag list in the offer, and pe identification-tag in the identification-tag list in the offer and per
rform the same criteria form the same criteria
check for the "m=" section indicated by that identification-tag. If th ere are no check for the "m=" section indicated by that identification-tag. If th ere are no
more identification-tags in the identification-tag list, the answerer MUST NOT more identification-tags in the identification-tag list, the answerer <bcp14>MUST NOT</bcp14>
create the BUNDLE group. Unless the answerer rejects the whole offer, create the BUNDLE group. Unless the answerer rejects the whole offer,
the answerer MUST apply the answerer procedures for moving an "m=" sec the answerer <bcp14>MUST</bcp14> apply the answerer procedures for mov
tion out of a ing an "m=" section out of a
BUNDLE group [<xref target="sec-sdp-oa-ans-mov" pageno="false" format= BUNDLE group (<xref target="sec-sdp-oa-ans-mov" format="default"/>) or
"default"/>] or rejecting an "m=" section within a BUNDLE group (<xref target="sec-sdp
rejecting an "m=" section within a BUNDLE group [<xref target="sec-sdp -oa-ans-rej" format="default"/>) to every bundled "m=" section in the offer when
-oa-ans-rej"
pageno="false" format="default"/>] to every bundled "m=" section in th
e offer when
creating the answer. creating the answer.
oa-ans-rej" <span class="insert">format="default"/&gt;)</span> to every bundled </t>
"m=" section in <span class="insert">the</span> offer when <t>
</t> <xref target="sec-example-add" format="default"/> shows an
<t>
[<xref target="sec-example-add" pageno="false" format="default"/>] sho
ws an
example of an offerer BUNDLE address:port selection. example of an offerer BUNDLE address:port selection.
</t> </t>
<t> <t>
[<xref target="sec-sdp-oa-ans-ex" pageno="false" format="default"/>] a Sections <xref target="sec-sdp-oa-ans-ex" format="counter"/> and
nd <xref target="sec-example-add" format="counter"/> show an example of a
[<xref target="sec-example-add" pageno="false" format="default"/>] sho n
w an example of an answerer-tagged "m=" section selection.
answerer tagged "m=" section selection. </t>
</t> </section>
</section> <section anchor="sec-sdp-oa-ans-mov" toc="default" numbered="true">
<name>Moving a Media Description Out of a BUNDLE Group</name>
<section title="Moving A Media Description Out Of A BUNDLE Group" anchor=" <t>
sec-sdp-oa-ans-mov" toc="default">
<t>
When an answerer generates the answer, if the answerer wants to move a bundled "m=" section out of When an answerer generates the answer, if the answerer wants to move a bundled "m=" section out of
the negotiated BUNDLE group, the answerer MUST first check the followi the negotiated BUNDLE group, the answerer <bcp14>MUST</bcp14> first ch
ng criteria: eck the following criteria:
<list style="symbols"> </t>
<t> <ul spacing="normal">
In the corresponding offer, the "m=" section is within a previousl <li>
y negotiated BUNDLE group; and In the corresponding offer, the "m=" section is within a previousl
</t> y negotiated BUNDLE group, and
<t> </li>
<li>
In the corresponding offer, the "m=" section contains an SDP 'bund le-only' attribute. In the corresponding offer, the "m=" section contains an SDP 'bund le-only' attribute.
</t> </li>
</list> </ul>
</t> <t>
<t> If either criterion above is fulfilled, the answerer cannot move the "
If either criterium above is fulfilled the answerer can not move the " m=" section out of
m=" section out of the BUNDLE group in the answer. The answerer can reject the whole offe
the BUNDLE group in the answer. The answerer can either reject the who r, reject each
le offer, reject each bundled "m=" section within the BUNDLE group (<xref target="sec-sdp-oa
bundled "m=" section within the BUNDLE group [<xref target="sec-sdp-oa -ans-rej" format="default"/>),
-ans-rej" pageno="false" format="default"/>],
or keep the "m=" section within the BUNDLE group in the answer and lat er create an offer where or keep the "m=" section within the BUNDLE group in the answer and lat er create an offer where
ans-rej" <span class="insert">format="default"/&gt;),</span> the "m=" section is moved out of the BUNDLE group (<xref target="sec-s
the "m=" section is moved out of the BUNDLE group [<xref target="sec-s dp-oa-mod-mov" format="default"/>).
dp-oa-mod-mov" </t>
pageno="false" format="default"/>]. <t>
</t>
<t>
NOTE: One consequence of the rules above is that, once a BUNDLE group has been negotiated, a bundled "m=" section NOTE: One consequence of the rules above is that, once a BUNDLE group has been negotiated, a bundled "m=" section
can not be moved out of the BUNDLE group in an answer. Instead an offe cannot be moved out of the BUNDLE group in an answer. Instead, an offe
r is needed. r is needed.
</t> </t>
<t> <t>
When the answerer generates an answer, in which it moves a bundled "m= " section out When the answerer generates an answer, in which it moves a bundled "m= " section out
of a BUNDLE group, the answerer: of a BUNDLE group, the answerer:
<list style="symbols">
<t>
MUST assign a unique address:port to the "m=" section; and
</t> </t>
<ul spacing="normal">
<li>
<bcp14>MUST</bcp14> assign a unique address:port to the "m=" section;
</li>
<li>
<bcp14>MUST</bcp14> include any applicable SDP attribute in the "m="
section, using the normal
offer/answer procedures for each attribute;
</li>
<li>
<bcp14>MUST NOT</bcp14> place the identification-tag associated with
the "m=" section in
the SDP 'group:BUNDLE' attribute identification-tag list associated
with
the BUNDLE group; and
</li>
<li>
<bcp14>MUST NOT</bcp14> include an SDP 'bundle-only' attribute to th
e "m=" section.
</li>
</ul>
<t> <t>
MUST include any applicable SDP attribute in the "m=" section, using Because an answerer is not allowed to move an "m=" section from one BU
the normal NDLE group to another within an answer
offer/answer procedures for the each Attributes; and (<xref target="sec-sdp-oa-ans" format="default"/>), if
the answerer wants to move an "m=" section from one BUNDLE group to an
other, it <bcp14>MUST</bcp14> first move the
"m=" section out of the current BUNDLE group and then generate an offe
r where the "m=" section is
added to another BUNDLE group (<xref target="sec-sdp-oa-mod-add" forma
t="default"/>).
</t> </t>
</section>
<section anchor="sec-sdp-oa-ans-rej" toc="default" numbered="true">
<name>Rejecting a Media Description in a BUNDLE Group</name>
<t> <t>
MUST NOT place the identification-tag associated with the "m=" secti When an answerer wants to reject a bundled "m=" section in an answer,
on in it <bcp14>MUST</bcp14> first check
the SDP 'group:BUNDLE' attribute identification-tag list associated the following criterion:
with
the BUNDLE group.
</t> </t>
<ul spacing="normal">
<li>
In the corresponding offer, the "m=" section is the offerer-tagged "
m=" section.
</li>
</ul>
<t> <t>
MUST NOT include an SDP 'bundle-only' attribute to the "m=" section; If the criterion above is fulfilled, the answerer cannot reject the "m
and =" section in
the answer. The answerer can reject the whole offer, reject each bundl
ed "m=" section
within the BUNDLE group, or keep the "m=" section within the BUNDLE gr
oup in the answer and later create
an offer where the "m=" section is disabled within the BUNDLE group (<
xref target="sec-sdp-oa-mod-dis" format="default"/>).
</t> </t>
</list>
</t>
<t>
Because an answerer is not allowed to move an "m=" section from one BU
NDLE group to another within an answer
[<xref target="sec-sdp-oa-ans" pageno="false" format="default"/>], if
the answerer wants to move an "m=" section from one BUNDLE group to an
other it MUST first move the
"m=" section out of the current BUNDLE group, and then generate an off
er where the "m=" section is
added to another BUNDLE group [<xref target="sec-sdp-oa-mod-add" pagen
o="false" format="default"/>].
</t>
</section>
<section title="Rejecting a Media Description in a BUNDLE Group" anchor="s
ec-sdp-oa-ans-rej" toc="default">
<t>
When an answerer wants to reject a bundled "m=" section in an answer,
it MUST first check
the following criterion:
<list style="symbols">
<t> <t>
In the corresponding offer, the "m=" section is the offerer tagged "
m=" section.
</t>
</list>
</t>
<t>
If the criterium above is fulfilled the answerer can not reject the "m
=" section in
the answer. The answerer can either reject the whole offer, reject eac
h bundled "m=" section
within the BUNDLE group, or keep the "m=" section within the BUNDLE gr
oup in the answer and later create
an offer where the "m=" section is disabled within the BUNDLE group [<
xref target="sec-sdp-oa-mod-dis"
pageno="false" format="default"/>].
</t>
<t>
When an answerer generates an answer, in which it rejects a bundled "m =" section, When an answerer generates an answer, in which it rejects a bundled "m =" section,
the answerer: the answerer:
<list style="symbols">
<t>
MUST assign a zero port value to the "m=" section, according to the
procedures in
<xref target="RFC3264" pageno="false" format="default"/>; and
</t> </t>
<t> <ul spacing="normal">
MUST NOT place the identification-tag associated with the "m=" secti <li>
on in <bcp14>MUST</bcp14> assign a zero port value to the "m=" section, ac
cording to the procedures in
<xref target="RFC3264" format="default"/>;
</li>
<li>
<bcp14>MUST NOT</bcp14> place the identification-tag associated with
the "m=" section in
the SDP 'group:BUNDLE' attribute identification-tag list associated with the SDP 'group:BUNDLE' attribute identification-tag list associated with
the BUNDLE group; and the BUNDLE group; and
</t> </li>
<li>
<bcp14>MUST NOT</bcp14> include an SDP 'bundle-only' attribute in th
e "m=" section.
</li>
</ul>
</section>
<section anchor="sec-sdp-oa-ans-ex" numbered="true" toc="default">
<name>Example: SDP Answer</name>
<t> <t>
MUST NOT include an SDP 'bundle-only' attribute in the "m=" section.
</t>
</list>
</t>
</section>
<section title="Example: SDP Answer" anchor="sec-sdp-oa-ans-ex">
<t>
The example below shows an answer, based on the corresponding offer in The example below shows an answer, based on the corresponding offer in
[<xref target="sec-sdp-oa-ino-ex" pageno="false" format="default"/>]. <xref target="sec-sdp-oa-ino-ex" format="default"/>.
The answerer accepts both bundled "m=" sections within the created The answerer accepts both bundled "m=" sections within the created
BUNDLE group. The audio "m=" section is the answerer tagged "m=" secti on, indicated BUNDLE group. The audio "m=" section is the answerer-tagged "m=" secti on, indicated
by placing the identification-tag associated with the "m=" section by placing the identification-tag associated with the "m=" section
(answerer BUNDLE-tag) first in the SDP group;BUNDLE attribute (answerer BUNDLE-tag) first in the SDP group;BUNDLE attribute
identification-id list. The answerer includes an SDP 'bundle-only' identification-id list. The answerer includes an SDP 'bundle-only'
attribute in, and assigns a zero port value to, the video "m=" section . attribute in, and assigns a zero port value to, the video "m=" section .
</t> </t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Answer <t keepWithNext="true">SDP Answer</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
]]></sourcecode>
]]></artwork> </section>
</figure>
</section> </section>
</section> <section anchor="sec-sdp-oa-off-ans" toc="default" numbered="true">
<name>Offerer Processing of the SDP Answer</name>
<section anchor="sec-sdp-oa-off-ans" title="Offerer Processing of the SDP An <t>
swer" toc="default">
<t>
When an offerer receives an answer, if the answer contains a BUNDLE grou p, the offerer When an offerer receives an answer, if the answer contains a BUNDLE grou p, the offerer
MUST check that any bundled "m=" section in the answer was indicated as <bcp14>MUST</bcp14> check that any bundled "m=" section in the answer wa
bundled in the s indicated as bundled in the
corresponding offer. If there is no mismatch, the offerer MUST apply the corresponding offer. If there is no mismatch, the offerer <bcp14>MUST</b
properties (BUNDLE address:port, cp14> apply the properties (BUNDLE address:port,
BUNDLE attributes etc) of the offerer tagged "m=" section (selected by t BUNDLE attributes, etc.) of the offerer-tagged "m=" section (selected by
he answerer the answerer; see
[<xref format="default" pageno="false" target="sec-sdp-oa-ans-off"/>]) t <xref format="default" target="sec-sdp-oa-ans-off"/>) to each bundled "m
o each bundled "m=" section =" section
within the BUNDLE group. within the BUNDLE group.
</t> </t>
<t> <t>
NOTE: As the answerer might reject one or more bundled "m=" sections in an initial BUNDLE offer, NOTE: As the answerer might reject one or more bundled "m=" sections in an initial BUNDLE offer,
or move a bundled "m=" section out of a BUNDLE group, a given bundled "m =" section in the or move a bundled "m=" section out of a BUNDLE group, a given bundled "m =" section in the
offer might not be indicated as bundled in the corresponding answer. offer might not be indicated as bundled in the corresponding answer.
</t> </t>
<t> <t>
If the answer does not contain a BUNDLE group, the offerer MUST process If the answer does not contain a BUNDLE group, the offerer <bcp14>MUST</
the answer bcp14> process the answer
as a normal answer. as a normal answer.
</t> </t>
</section> </section>
<section anchor="sec-sdp-oa-mod" toc="default" numbered="true">
<section title="Modifying the Session" anchor="sec-sdp-oa-mod" toc="default" <name>Modifying the Session</name>
> <t>
<t> When a BUNDLE group has been previously negotiated, and an offerer gen
When a BUNDLE group has previously been negotiated, and an offerer gen erates a subsequent
erates a subsequent offer, the offerer <bcp14>MUST</bcp14>:
offer, the offerer MUST: </t>
<list style="symbols"> <ul spacing="normal">
<t> <li>
Pick one bundled "m=" section as the offerer tagged "m=" section. Pick one bundled "m=" section as the offerer-tagged "m=" section.
The offerer The offerer
can either pick the "m=" section that was previously selected by t can pick either the "m=" section that was previously selected by t
he answerer he answerer
as the offerer tagged "m=" section, or pick another bundled "m=" s as the offerer-tagged "m=" section or another bundled "m=" section
ection within the within the
BUNDLE group; and BUNDLE group;
</t> </li>
<t> <li>
Assign a BUNDLE address:port (previously negotiated or newly sugge Assign a BUNDLE address:port (previously negotiated or newly sugge
st) to sted) to
the offerer tagged "m=" section; and the offerer-tagged "m=" section;
</t> </li>
<t> <li>
Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every
other bundled "m=" section within the BUNDLE group; and other bundled "m=" section within the BUNDLE group;
</t> </li>
<t> <li>
Include SDP attributes in the bundled "m=" sections following the rules in Include SDP attributes in the bundled "m=" sections following the rules in
[<xref target="sec-sdp-oa-cat" pageno="false" format="default"/>]; <xref target="sec-sdp-oa-cat" format="default"/>;
and </li>
</t> <li>
<t>
Include an SDP 'group:BUNDLE' attribute in the offer; and Include an SDP 'group:BUNDLE' attribute in the offer; and
</t> </li>
<t> <li>
Place the identification-tag of each bundled "m=" section in the Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag
indicates the offerer tagged "m=" section. indicates the offerer-tagged "m=" section.
</t> </li>
</list> </ul>
</t>
<t> <t>
The offerer MUST NOT pick a given bundled "m=" section as the offerer The offerer <bcp14>MUST NOT</bcp14> pick a given bundled "m=" section
tagged "m=" section if: as the offerer-tagged "m=" section if:
<list style="symbols">
<t>
The offerer wants to move the "m=" section out of the BUNDLE group
[<xref target="sec-sdp-oa-mod-mov" pageno="false" format="default"
/>]; or
</t>
<t>
The offerer wants to disable the "m=" section [<xref format="defau
lt"
pageno="false" target="sec-sdp-oa-mod-dis"/>].
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
The offerer wants to move the "m=" section out of the BUNDLE group
(<xref target="sec-sdp-oa-mod-mov" format="default"/>), or
</li>
<li>
The offerer wants to disable the "m=" section (<xref format="defau
lt" target="sec-sdp-oa-mod-dis"/>).
</li>
</ul>
<t> <t>
The offerer can modify the offerer BUNDLE address:port, add and remove SDP attributes, or modify The offerer can modify the offerer BUNDLE address:port, add and remove SDP attributes, or modify
SDP attribute values, in the subsequent offer. Changes to the offerer BUNDLE address:port and the SDP attribute values in the subsequent offer. Changes to the offerer B UNDLE address:port and the
offerer BUNDLE attributes will (if the offer is accepted by the answer er) be applied to each offerer BUNDLE attributes will (if the offer is accepted by the answer er) be applied to each
bundled "m=" section within the BUNDLE group. bundled "m=" section within the BUNDLE group.
</t> </t>
<section title="Adding a Media Description to a BUNDLE group" anchor="sec- <section anchor="sec-sdp-oa-mod-add" toc="default" numbered="true">
sdp-oa-mod-add" toc="default"> <name>Adding a Media Description to a BUNDLE Group</name>
<t> <t>
When an offerer generates a subsequent offer, in which it wants to add a bundled "m=" section to When an offerer generates a subsequent offer, in which it wants to add a bundled "m=" section to
a previously negotiated BUNDLE group, the offerer follows the procedur a previously negotiated BUNDLE group, the offerer follows the procedur
es in <xref target="sec-sdp-oa-mod" es in <xref target="sec-sdp-oa-mod" format="default"/>. The offerer picks either
pageno="false" format="default"/>. The offerer either picks the added the added "m=" section or an "m=" section
"m=" section, or an "m=" section previously added to the BUNDLE group as the offerer-tagged "m=" sectio
previously added to the BUNDLE group, as the offerer tagged "m=" secti n.
on. </t>
</t> <t>
<t> NOTE: As described in <xref target="sec-sdp-oa-ans-mov" format="defaul
NOTE: As described in <xref target="sec-sdp-oa-ans-mov" pageno="false" t"/>, the answerer cannot move the added "m=" section
format="default"/>, the answerer can not move the added "m=" section
out of the BUNDLE group in its answer. If the answer wants to move the "m=" section out of the BUNDLE group, it will have to first accept out of the BUNDLE group in its answer. If the answer wants to move the "m=" section out of the BUNDLE group, it will have to first accept
it into the BUNDLE group in the answer, and then send a subsequent off er where the "m=" section is moved out of the BUNDLE group it into the BUNDLE group in the answer, and then send a subsequent off er where the "m=" section is moved out of the BUNDLE group
[<xref target="sec-sdp-oa-mod-mov" pageno="false" format="default"/>]. (<xref target="sec-sdp-oa-mod-mov" format="default"/>).
</t>
</section>
<section title="Moving a Media Description Out of a BUNDLE Group" anchor="
sec-sdp-oa-mod-mov" toc="default">
<t>
When an offerer generates a subsequent offer, in which it want to remo
ve a bundled "m=" section from
a BUNDLE group, the offerer:
<list style="symbols">
<t>
MUST assign a unique address:port to the "m=" section; and
</t> </t>
</section>
<section anchor="sec-sdp-oa-mod-mov" toc="default" numbered="true">
<name>Moving a Media Description Out of a BUNDLE Group</name>
<t> <t>
MUST include SDP attributes in the "m=" section following the When an offerer generates a subsequent offer, in which it wants to rem
normal offer/answer rules for each attribute; and ove a bundled "m=" section from
a BUNDLE group, the offerer:
</t> </t>
<t> <ul spacing="normal">
MUST NOT place the identification-tag associated with the "m=" secti <li>
on in <bcp14>MUST</bcp14> assign a unique address:port to the "m=" section
;
</li>
<li>
<bcp14>MUST</bcp14> include SDP attributes in the "m=" section follo
wing the
normal offer/answer rules for each attribute;
</li>
<li>
<bcp14>MUST NOT</bcp14> place the identification-tag associated with
the "m=" section in
the SDP 'group:BUNDLE' attribute identification-tag list associated with the SDP 'group:BUNDLE' attribute identification-tag list associated with
the BUNDLE group; and the BUNDLE group; and
</t> </li>
<li>
<bcp14>MUST NOT</bcp14> assign an SDP 'bundle-only' attribute to the
"m=" section.
</li>
</ul>
<t> <t>
MUST NOT assign an SDP 'bundle-only' attribute to the "m=" section.
</t>
</list>
</t>
<t>
For the other bundled "m=" sections within the BUNDLE group, the offer er follows the procedures For the other bundled "m=" sections within the BUNDLE group, the offer er follows the procedures
in [<xref target="sec-sdp-oa-mod" pageno="false" format="default"/>]. in <xref target="sec-sdp-oa-mod" format="default"/>.
</t> </t>
<t> <t>
An offerer MUST NOT move an "m=" section from one BUNDLE group to anot An offerer <bcp14>MUST NOT</bcp14> move an "m=" section from one BUNDL
her within a E group to another within a
single offer. If the offerer wants to move an "m=" section from one BU NDLE group to single offer. If the offerer wants to move an "m=" section from one BU NDLE group to
another it MUST first move the BUNDLE group out of the current BUNDLE group, and then another, it <bcp14>MUST</bcp14> first move the BUNDLE group out of the current BUNDLE group, and then
generate a second offer where the "m=" section is added to another BUN DLE group generate a second offer where the "m=" section is added to another BUN DLE group
[<xref target="sec-sdp-oa-mod-add" pageno="false" format="default"/>]. (<xref target="sec-sdp-oa-mod-add" format="default"/>).
</t> </t>
<t>
[<xref target="sec-example-off-mov" pageno="false" format="default"/>]
shows an example of an offer for moving an "m=" section out of a BUNDL
E group.
</t>
</section>
<section title="Disabling a Media Description in a BUNDLE Group" anchor="s
ec-sdp-oa-mod-dis" toc="default">
<t>
When an offerer generates a subsequent offer, in which it want to disa
ble a bundled "m=" section from
a BUNDLE group, the offerer:
<list style="symbols">
<t> <t>
MUST assign a zero port value to the "m=" section, following the pro <xref target="sec-example-off-mov" format="default"/>
cedures shows an example of an offer for moving an "m=" section out of a BUNDL
in <xref target="RFC4566" pageno="false" format="default"/>; and E group.
</t> </t>
</section>
<section anchor="sec-sdp-oa-mod-dis" toc="default" numbered="true">
<name>Disabling a Media Description in a BUNDLE Group</name>
<t> <t>
MUST NOT place the identification-tag associated with the "m=" secti When an offerer generates a subsequent offer, in which it wants to dis
on in able a bundled "m=" section from
a BUNDLE group, the offerer:
</t>
<ul spacing="normal">
<li>
<bcp14>MUST</bcp14> assign a zero port value to the "m=" section, fo
llowing the procedures
in <xref target="RFC4566" format="default"/>;
</li>
<li>
<bcp14>MUST NOT</bcp14> place the identification-tag associated with
the "m=" section in
the SDP 'group:BUNDLE' attribute identification-tag list associated with the SDP 'group:BUNDLE' attribute identification-tag list associated with
the BUNDLE group; and the BUNDLE group; and
</t> </li>
<li>
<bcp14>MUST NOT</bcp14> assign an SDP 'bundle-only' attribute to the
"m=" section.
</li>
</ul>
<t> <t>
MUST NOT assign an SDP 'bundle-only' attribute to the "m=" section.
</t>
</list>
</t>
<t>
For the other bundled "m=" sections within the BUNDLE group, the offer er follows the procedures For the other bundled "m=" sections within the BUNDLE group, the offer er follows the procedures
in [<xref target="sec-sdp-oa-mod" pageno="false" format="default"/>]. in <xref target="sec-sdp-oa-mod" format="default"/>.
</t> </t>
<t> <t>
[<xref target="sec-example-off-dis" pageno="false" format="default"/>] <xref target="sec-example-off-dis" format="default"/>
shows an example of an offer and answer for disabling an "m=" section within a shows an example of an offer and answer for disabling an "m=" section within a
BUNDLE group. BUNDLE group.
</t> </t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="sec-protocol-id" toc="default" numbered="true">
<name>Protocol Identification</name>
<section title="Protocol Identification" anchor="sec-protocol-id" toc="default <t>
"> Each "m=" section within a BUNDLE group <bcp14>MUST</bcp14> use the same t
<t> ransport-
Each "m=" section within a BUNDLE group MUST use the same transport-
layer protocol. If bundled "m=" sections use different upper-layer protoco ls layer protocol. If bundled "m=" sections use different upper-layer protoco ls
on top of the transport-layer protocol, there MUST exist a publicly on top of the transport-layer protocol, there <bcp14>MUST</bcp14> exist a
available specification which describes a mechanism how to associate publicly
available specification that describes how a mechanism associates
received data with the correct protocol for this particular protocol combi nation. received data with the correct protocol for this particular protocol combi nation.
</t> </t>
<t> <t>
In addition, if received data can be associated with more than In addition, if received data can be associated with more than
one bundled "m=" section, there MUST exist a publicly available one bundled "m=" section, there <bcp14>MUST</bcp14> exist a publicly avail
specification which describes a mechanism for associating the able
specification that describes a mechanism for associating the
received data with the correct "m=" section. received data with the correct "m=" section.
</t> </t>
<t> <t>
This document describes a mechanism to identify the This document describes a mechanism to identify the
protocol of received data among the STUN, DTLS and SRTP protocols protocol of received data among the Session Traversal Utilities for NAT (S
(in any combination), when UDP is used as transport-layer protocol, TUN), DTLS, and the Secure Real-time Transport Protocol (SRTP)
(in any combination) when UDP is used as a transport-layer protocol,
but it does not describe how to identify different protocols transported o n but it does not describe how to identify different protocols transported o n
DTLS. While the mechanism is generally applicable to other protocols and DTLS.
transport-layer protocols, any such use requires further specification aro While the mechanism is generally applicable to other protocols and
und transport-layer protocols, any such use requires further specification
how to multiplex multiple protocols on a given transport-layer protocol, that encompasses how to multiplex multiple protocols on a given transport-
layer protocol
and how to associate received data with the correct protocols. and how to associate received data with the correct protocols.
</t> </t>
<section anchor="sec-packets-id-sds" title="STUN, DTLS, SRTP" toc="default"> <section anchor="sec-packets-id-sds" toc="default" numbered="true">
<t> <name>STUN, DTLS, and SRTP</name>
Section 5.1.2 of <xref format="default" pageno="false" target="RFC5764"/ <t>
> describes a Section 5.1.2 of <xref format="default" target="RFC5764"/> describes a
mechanism to identify the protocol of a received packet among the STUN, mechanism to identify the protocol of a received packet among the STUN,
DTLS and DTLS, and
SRTP protocols (in any combination). SRTP protocols (in any combination).
If an offer or answer includes a bundled "m=" section that represents th ese protocols, the offerer If an offer or answer includes a bundled "m=" section that represents th ese protocols, the offerer
or answerer MUST support the mechanism described in <xref format="defaul or answerer <bcp14>MUST</bcp14> support the mechanism described in <xref
t" pageno="false" format="default" target="RFC5764"/>, and no explicit negotiation is required in
target="RFC5764"/>, and no explicit negotiation is required in order to order to indicate support
indicate support
and usage of the mechanism. and usage of the mechanism.
</t> </t>
<t> <t>
<xref format="default" pageno="false" target="RFC5764"/> does not descri <xref format="default" target="RFC5764"/> does not describe how to ident
be how to identify ify
different protocols transported on DTLS, only how to identify the DTLS p rotocol itself. If different protocols transported on DTLS, only how to identify the DTLS p rotocol itself. If
multiple protocols are transported on DTLS, there MUST exist a specifica tion describing a multiple protocols are transported on DTLS, there <bcp14>MUST</bcp14> ex ist a specification describing a
mechanism for identifying each individual protocol. In addition, if a re ceived DTLS packet mechanism for identifying each individual protocol. In addition, if a re ceived DTLS packet
can be associated with more than one "m=" section, there MUST exist a sp ecification which can be associated with more than one "m=" section, there <bcp14>MUST</bc p14> exist a specification that
describes a mechanism for associating the received DTLS packets with the correct "m=" section. describes a mechanism for associating the received DTLS packets with the correct "m=" section.
</t> </t>
<t> <t>
[<xref format="default" pageno="false" target="sec-rtp-pt"/>] describes <xref format="default" target="sec-rtp-pt"/> describes how to
how to
associate the packets in a received SRTP stream with the correct "m=" se ction. associate the packets in a received SRTP stream with the correct "m=" se ction.
</t> </t>
</section>
</section> </section>
</section> <section anchor="sec-rtp" toc="default" numbered="true">
<name>RTP Considerations</name>
<section anchor="sec-rtp" title="RTP Considerations" toc="default"> <section anchor="sec-rtp-sessions" toc="default" numbered="true">
<section anchor="sec-rtp-sessions" title="Single RTP Session" toc="default"> <name>Single RTP Session</name>
<t> <t>
All RTP-based media within a single BUNDLE group belong to a All RTP-based media within a single BUNDLE group belong to a
single RTP session <xref format="default" pageno="false" single RTP session <xref format="default" target="RFC3550"/>.
target="RFC3550"/>. </t>
</t> <t>
<t>
Since a single BUNDLE transport is used for sending and receiving bu ndled media, Since a single BUNDLE transport is used for sending and receiving bu ndled media,
the symmetric RTP mechanism <xref format="default" pageno="false" ta the symmetric RTP mechanism <xref format="default" target="RFC4961"/
rget="RFC4961"/> >
MUST be used for RTP-based bundled media. <bcp14>MUST</bcp14> be used for RTP-based bundled media.
</t> </t>
<t> <t>
Since a single RTP session is used for each BUNDLE group, all Since a single RTP session is used for each BUNDLE group, all
"m=" sections representing RTP-based media within a BUNDLE group wil l "m=" sections representing RTP-based media within a BUNDLE group wil l
share a single SSRC numbering space <xref format="default" share a single Synchronization Source (SSRC) numbering space <xref f
pageno="false" target="RFC3550"/>. ormat="default" target="RFC3550"/>.
</t> </t>
<t> <t>
The following rules and restrictions apply for a single RTP The following rules and restrictions apply for a single RTP
session: session:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t>
A specific payload type value can be used in multiple bundled "m =" sections A specific payload type value can be used in multiple bundled "m =" sections
only if each codec associated with the payload type number share s an identical only if each codec associated with the payload type number share s an identical
codec configuration [<xref format="default" pageno="false" codec configuration (<xref format="default" target="sec-rtp-sess
target="sec-rtp-sessions-pt"/>]. ions-pt"/>).
</t> </li>
<t> <li>
The proto value in each bundled RTP-based "m=" section MUST be i The proto value in each bundled RTP-based "m=" section <bcp14>MU
dentical ST</bcp14> be identical
(e.g., RTP/AVPF). (e.g., RTP/AVPF).
</t> </li>
<t> <li>
The RTP MID header extension MUST be enabled, by including The RTP MID header extension <bcp14>MUST</bcp14> be enabled, by
an SDP 'extmap' attribute <xref format="default" pageno="false" including
target="RFC8285"/>, an SDP 'extmap' attribute <xref format="default" target="RFC8285
with a 'urn:ietf:params:rtp- hdrext:sdes:mid' URI value, in each "/>,
with an 'urn:ietf:params:rtp- hdrext:sdes:mid' URI value, in eac
h
bundled RTP-based "m=" section in every offer and answer. bundled RTP-based "m=" section in every offer and answer.
</t> </li>
<t> <li>
A given SSRC MUST NOT transmit RTP packets using payload types t A given SSRC <bcp14>MUST NOT</bcp14> transmit RTP packets using
hat payload types that
originate from different bundled "m=" sections. originate from different bundled "m=" sections.
</t> </li>
</list> </ul>
</t> <t>
<t>
NOTE: The last bullet above is to avoid sending multiple media types NOTE: The last bullet above is to avoid sending multiple media types
from the same SSRC. If transmission of multiple media types are done from the same SSRC. If transmission of multiple media types are done
with time overlap, RTP and RTCP fail to function. Even if done in with time overlap, RTP and RTCP fail to function. Even if done in
proper sequence this causes RTP Timestamp rate switching issues proper sequence, this causes RTP timestamp rate switching issues
<xref format="default" pageno="false" target="RFC7160"/>. However, <xref format="default" target="RFC7160"/>. However,
once an SSRC has left the RTP session (by sending an RTCP BYE packet ), once an SSRC has left the RTP session (by sending an RTCP BYE packet ),
that SSRC can be reused by another source (possibly associated that SSRC can be reused by another source (possibly associated
with a different bundled "m=" section) after a delay of 5 RTCP repor ting intervals with a different bundled "m=" section) after a delay of 5 RTCP repor ting intervals
(the delay is to ensure the SSRC has timed out, in case the RTCP BYE (the delay is to ensure the SSRC has timed out, in case the RTCP BYE
packet was lost <xref format="default" pageno="false" target="RFC355 packet was lost <xref format="default" target="RFC3550"/>).
0"/>). </t>
</t> <t>
<t> <xref format="default" target="RFC7657"/> defines Differentiated Ser
<xref format="default" pageno="false" target="RFC7657"/> defines Dif vices
ferentiated Services
(Diffserv) considerations for RTP-based bundled media sent using a m ixture of Diffserv Codepoints. (Diffserv) considerations for RTP-based bundled media sent using a m ixture of Diffserv Codepoints.
</t> </t>
<section anchor="sec-rtp-sessions-pt" title="Payload Type (PT) Value Reuse <section anchor="sec-rtp-sessions-pt" toc="default" numbered="true">
" toc="default"> <name>Payload Type (PT) Value Reuse</name>
<t> <t>
Multiple bundled "m=" sections might describe RTP based media. As al l RTP based Multiple bundled "m=" sections might describe RTP-based media. As al l RTP-based
media associated with a BUNDLE group belong to the same RTP session, in order media associated with a BUNDLE group belong to the same RTP session, in order
for a given payload type value to be used inside more than one bundl ed "m=" section, for a given payload type value to be used inside more than one bundl ed "m=" section,
all codecs associated with the payload type number MUST share an ide all codecs associated with the payload type number <bcp14>MUST</bcp1
ntical codec 4> share an identical codec
configuration. This means that the codecs MUST share the same media configuration. This means that the codecs <bcp14>MUST</bcp14> share
type, the same media type,
encoding name, clock rate and any parameter that can affect the code encoding name, clock rate, and any parameter that can affect the cod
c configuration ec configuration
and packetization. <xref format="default" pageno="false" and packetization. <xref format="default" target="RFC8859"/> lists S
target="I-D.ietf-mmusic-sdp-mux-attributes"/> lists SDP attributes, DP attributes, whose attribute
whose attribute values are required to be identical for all codecs that use the
values are required to be identical for all codecs that use the same same payload type value.
payload type value.
</t> </t>
</section>
</section> </section>
</section> <section anchor="sec-rtp-pt" toc="default" numbered="true">
<name>Associating RTP/RTCP Streams with the Correct SDP Media Descriptio
<section anchor="sec-rtp-pt" title="Associating RTP/RTCP Streams with the Co n</name>
rrect SDP Media Description" toc="default">
<t> <t>
As described in <xref target="RFC3550" />, RTP packets are associate As described in <xref target="RFC3550" format="default"/>, RTP packe
d with RTP ts are associated with RTP
streams <xref target="RFC7656" />. Each RTP stream is identified by streams <xref target="RFC7656" format="default"/>. Each RTP stream i
an SSRC s identified by an SSRC
value, and each RTP packet includes an SSRC field that is value, and each RTP packet includes an SSRC field that is
used to associate the packet with the correct RTP stream. used to associate the packet with the correct RTP stream.
RTCP packets also use SSRCs to identify which RTP streams the RTCP packets also use SSRCs to identify which RTP streams the
packet relates to. However, a RTCP packet can contain multiple SSRC packet relates to. However, an RTCP packet can contain multiple SSRC
fields, in the course of providing feedback or reports on different RTP fields, in the course of providing feedback or reports on different RTP
streams, and therefore can be associated with multiple such streams. streams, and therefore can be associated with multiple such streams.
</t> </t>
<t> <t>
In order to be able to process received RTP/RTCP packets In order to be able to process received RTP/RTCP packets
correctly, it MUST be possible to associate an RTP stream with correctly, it <bcp14>MUST</bcp14> be possible to associate an RTP st ream with
the correct "m=" section, as the "m=" section and SDP attributes the correct "m=" section, as the "m=" section and SDP attributes
associated with the "m=" section contains information needed to associated with the "m=" section contains information needed to
process the packets. process the packets.
</t> </t>
<t> <t>
As all RTP streams associated with a BUNDLE group use the As all RTP streams associated with a BUNDLE group use the
same transport for sending and receiving RTP/RTCP same transport for sending and receiving RTP/RTCP
packets, the local address:port combination part of the transport packets, the local address:port combination part of the transport
cannot be used to associate an RTP stream with the correct "m=" sect ion. cannot be used to associate an RTP stream with the correct "m=" sect ion.
In addition, multiple RTP streams might be associated with the same "m=" In addition, multiple RTP streams might be associated with the same "m="
section. section.
</t> </t>
<t> <t>
An offerer and answerer can inform each other which SSRC An offerer and answerer can inform each other which SSRC
values they will use for an RTP stream by using the SDP 'ssrc' values they will use for an RTP stream by using the SDP 'ssrc'
attribute <xref format="default" pageno="false" target="RFC5576"/>. attribute <xref format="default" target="RFC5576"/>.
However, an offerer will not know which SSRC values the However, an offerer will not know which SSRC values the
answerer will use until the offerer has received the answer answerer will use until the offerer has received the answer
providing that information. Due to this, before the offerer has providing that information. Due to this, before the offerer has
received the answer, the offerer will not be able to associate received the answer, the offerer will not be able to associate
an RTP stream with the correct "m=" section using the SSRC value an RTP stream with the correct "m=" section using the SSRC value
associated with the RTP stream. In addition, the offerer and associated with the RTP stream. In addition, the offerer and
answerer may start using new SSRC values mid-session, without answerer may start using new SSRC values mid-session, without
informing each other using the SDP 'ssrc' attribute. informing each other about using the SDP 'ssrc' attribute.
</t> </t>
<t> <t>
In order for an offerer and answerer to always be able to In order for an offerer and answerer to always be able to
associate an RTP stream with the correct "m=" section, the offerer associate an RTP stream with the correct "m=" section, the offerer
and answerer using the BUNDLE extension MUST support the and answerer using the BUNDLE extension <bcp14>MUST</bcp14> support
mechanism defined in <xref format="default" pageno="false" target="s the
ec-receiver-id"/>, mechanism defined in <xref format="default" target="sec-receiver-id"
/>,
where the offerer and answerer insert the identification-tag associa ted where the offerer and answerer insert the identification-tag associa ted
with an "m=" section (provided by the remote peer) into RTP and RTCP with an "m=" section (provided by the remote peer) into RTP and RTCP
packets associated with a BUNDLE group. packets associated with a BUNDLE group.
</t> </t>
<t> <t>
When using this mechanism, the mapping from an SSRC to an When using this mechanism, the mapping from an SSRC to an
identification-tag is carried in RTP header extensions or RTCP SDES identification-tag is carried in RTP header extensions or RTCP SDES
packets, as specified in <xref format="default" pageno="false" targ et="sec-receiver-id"/>. packets, as specified in <xref format="default" target="sec-receive r-id"/>.
Since a compound RTCP packet can contain multiple RTCP SDES packets , Since a compound RTCP packet can contain multiple RTCP SDES packets ,
and each RTCP SDES packet can contain multiple chunks, a single RTC P and each RTCP SDES packet can contain multiple chunks, a single RTC P
packet can contain several SSRC to identification-tag mappings. The packet can contain several mappings of SSRC to identification-tag. The
offerer and answerer maintain tables used for routing that are upda ted offerer and answerer maintain tables used for routing that are upda ted
each time an RTP/RTCP packet contains new information that affects how each time an RTP/RTCP packet contains new information that affects how
packets are to be routed. packets are to be routed.
</t> </t>
<t> <t>
However, some legacy implementations may not include this identifica tion-tag However, some legacy implementations may not include this identifica tion-tag
in their RTP and RTCP traffic when using the BUNDLE mechanism, and in their RTP and RTCP traffic when using the BUNDLE mechanism and
instead use a payload type based mechanism to associate RTP streams instead use a mechanism based on the payload type to associate RTP s
treams
with SDP "m=" sections. In this situation, each "m=" section needs to with SDP "m=" sections. In this situation, each "m=" section needs to
use unique payload type values, in order for the payload type to be a use unique payload type values, in order for the payload type to be a
reliable indicator of the relevant "m=" section for the RTP stream. If an reliable indicator of the relevant "m=" section for the RTP stream. If an
implementation fails to ensure unique payload type values it will be implementation fails to ensure unique payload type values, it will b e
impossible to associate the RTP stream using that payload type value impossible to associate the RTP stream using that payload type value
to a particular "m=" section. to a particular "m=" section.
Note that when using the payload type to associate RTP streams with Note that when using the payload type to associate RTP streams with
"m=" sections an RTP stream, identified by its SSRC, will be mapped "m=" sections, an RTP stream, identified by its SSRC, will be mapped
to an "m=" section when the first packet of that RTP stream is to an "m=" section when the first packet of that RTP stream is
received, and the mapping will not be changed even if the payload received, and the mapping will not be changed even if the payload
type used by that RTP stream changes. In other words, the SSRC type used by that RTP stream changes. In other words, the SSRC
cannot "move" to a different "m=" section simply by changing the cannot "move" to a different "m=" section simply by changing the
payload type. payload type.
</t> </t>
<t> <t>
Applications can implement RTP stacks in many different Applications can implement RTP stacks in many different
ways. The algorithm below details one way that RTP streams can be ways. The algorithm below details one way that RTP streams can be
associated with "m=" sections, but is not meant to be prescriptive associated with "m=" sections, but it is not meant to be prescripti ve
about exactly how an RTP stack needs to be implemented. about exactly how an RTP stack needs to be implemented.
Applications MAY use any algorithm that achieves equivalent results to Applications <bcp14>MAY</bcp14> use any algorithm that achieves equ ivalent results to
those described in the algorithm below. those described in the algorithm below.
</t> </t>
<t> <t>
To prepare to associate RTP streams with the correct To prepare to associate RTP streams with the correct
"m=" section, the following steps MUST be followed for each BUNDLE "m=" section, the following steps <bcp14>MUST</bcp14> be followed f
group: or each BUNDLE group:
</t> </t>
<t><list>
<t> <ul empty="false" spacing="normal">
Construct a table mapping MID to "m=" section for each "m=" <li>
Construct a table mapping a MID to an "m=" section for each "m=
"
section in this BUNDLE group. Note that an "m=" section may onl y section in this BUNDLE group. Note that an "m=" section may onl y
have one MID. have one MID.
</t> </li>
<t> <li>
Construct a table mapping SSRCs of incoming RTP streams to "m=" Construct a table mapping SSRCs of incoming RTP streams to an "
section for m=" section for
each "m=" section in this BUNDLE group and for each SSRC each "m=" section in this BUNDLE group and for each SSRC
configured for receiving in that "m=" section. configured for receiving in that "m=" section.
</t> </li>
<t> <li>
Construct a table mapping the SSRC of each outgoing RTP stream Construct a table mapping the SSRC of each outgoing RTP stream
to "m=" section for each "m=" section in this BUNDLE group and for each SSRC to an "m=" section for each "m=" section in this BUNDLE group a nd for each SSRC
configured for sending in that "m=" section. configured for sending in that "m=" section.
</t> </li>
<t> <li>
Construct a table mapping payload type to "m=" section for Construct a table mapping a payload type to an "m=" section for
each "m=" section in the BUNDLE group and for each payload type each "m=" section in the BUNDLE group and for each payload type
configured for receiving in that "m=" section. If any payload configured for receiving in that "m=" section. If any payload
type is configured for receiving in more than one "m=" section type is configured for receiving in more than one "m=" section
in the BUNDLE group, do not include it in the table, as it in the BUNDLE group, do not include it in the table, as it
cannot be used to uniquely identify an "m=" section. cannot be used to uniquely identify an "m=" section.
</t> </li>
<t> <li>
Note that for each of these tables, there can only be one Note that for each of these tables, there can only be one
mapping for any given key (MID, SSRC, or PT). In other mapping for any given key (MID, SSRC, or PT). In other
words, the tables are not multimaps. words, the tables are not multimaps.
</t> </li>
</list></t> </ul>
<t> <t>
As "m=" sections are added or removed from the BUNDLE groups, or As "m=" sections are added or removed from the BUNDLE groups, or
their configurations are changed, the tables above MUST also be their configurations are changed, the tables above <bcp14>MUST</bcp 14> also be
updated. updated.
</t> </t>
<t> <t>
When an RTP packet is received, it MUST be delivered to the RTP When an RTP packet is received, it <bcp14>MUST</bcp14> be delivered
stream corresponding to its SSRC. That RTP stream MUST then be to the RTP
stream corresponding to its SSRC. That RTP stream <bcp14>MUST</bcp1
4> then be
associated with the correct "m=" section within a BUNDLE group, for associated with the correct "m=" section within a BUNDLE group, for
additional processing, according to the following steps: additional processing, according to the following steps:
</t> </t>
<t><list> <ul empty="false" spacing="normal">
<t> <li>
If the MID associated with the RTP stream is not in the If the MID associated with the RTP stream is not in the
table mapping MID to "m=" section, then the RTP stream is not table mapping a MID to an "m=" section, then the RTP stream is not
decoded and the payload data is discarded. decoded and the payload data is discarded.
</t> </li>
<t> <li>
If the packet has a MID, and the packet's extended sequence num ber If the packet has a MID, and the packet's extended sequence num ber
is greater than that of the last MID update, as discussed in is greater than that of the last MID update, as discussed in
<xref target="RFC7941" />, Section 4.2.6, update the MID associ <xref target="RFC7941" sectionFormat="comma" section="4.2.2"/>,
ated update the MID associated
with the RTP stream to match the MID carried in the RTP packet, with the RTP stream to match the MID carried in the RTP packet,
then and then
update the mapping tables to include an entry that maps the SSR C of update the mapping tables to include an entry that maps the SSR C of
that RTP stream to the "m=" section for that MID. that RTP stream to the "m=" section for that MID.
</t> </li>
<t> <li>
If the SSRC of the RTP stream is in the incoming SSRC If the SSRC of the RTP stream is in the incoming SSRC
mapping table, check that the payload type used by the RTP mapping table, check that the payload type used by the RTP
stream matches a payload type included on the matching stream matches a payload type included on the matching
"m=" section. If so, associate the RTP stream with that "m=" section. If so, associate the RTP stream with that
"m=" section. Otherwise, the RTP stream is not decoded and the "m=" section. Otherwise, the RTP stream is not decoded and the
payload data is discarded. payload data is discarded.
</t> </li>
<t> <li>
If the payload type used by the RTP stream is in the If the payload type used by the RTP stream is in the
payload type table, update the incoming SSRC mapping table payload type table, update the incoming SSRC mapping table
to include an entry that maps the RTP stream's SSRC to the to include an entry that maps the RTP stream's SSRC to the
"m=" section for that payload type. Associate the RTP stream "m=" section for that payload type. Associate the RTP stream
with the corresponding "m=" section. with the corresponding "m=" section.
</t> </li>
<t> <li>
Otherwise, mark the RTP stream as not for decoding and Otherwise, mark the RTP stream as "not for decoding" and
discard the payload. discard the payload.
</t> </li>
</list> </ul>
If the RTP packet contains one or more contributing source (CSRC) <t>
identifiers, then each CSRC is looked up in the incoming SSRC table If the RTP packet contains one or more Contributing Source (CSRC)
identifiers, then each CSRC is looked up in the incoming SSRC table,
and a copy of the RTP packet is associated with the corresponding and a copy of the RTP packet is associated with the corresponding
"m=" section for additional processing. "m=" section for additional processing.
</t> </t>
<t> <t>
For each RTCP packet received (including each RTCP packet that is For each RTCP packet received (including each RTCP packet that is
part of a compound RTCP packet), the packet is processed as usual by part of a compound RTCP packet), the packet is processed as usual by
the RTP layer, then associated with the appropriate "m=" sections, and the RTP layer, then associated with the appropriate "m=" sections, and
processed for the RTP streams represented by those "m=" sections. processed for the RTP streams represented by those "m=" sections.
This routing is type-dependent, as each kind of RTCP packet has it s own This routing is type dependent, as each kind of RTCP packet has it s own
mechanism for associating it with the relevant RTP streams. mechanism for associating it with the relevant RTP streams.
</t> </t>
<t> <t>
RTCP packets that cannot be associated with an appropriate "m=" se ction RTCP packets that cannot be associated with an appropriate "m=" se ction
MUST still be processed as usual by the RTP layer, updating the me tadata <bcp14>MUST</bcp14> still be processed as usual by the RTP layer, which updates the metadata
associated with the corresponding RTP streams. This situation can occur with associated with the corresponding RTP streams. This situation can occur with
certain multiparty RTP topologies, or when RTCP packets are sent c ontaining certain multiparty RTP topologies or when RTCP packets are sent co ntaining
a subset of the SDES information. a subset of the SDES information.
</t> </t>
<t> <t>
Additional rules for processing various types of RTCP packets are Additional rules for processing various types of RTCP packets are
explained below. explained below.
</t> </t>
<t><list> <ul empty="false" spacing="normal">
<t> <li>
If the RTCP packet is of type SDES, for each chunk in the packet If the RTCP packet is of type SDES, for each chunk in the packet
whose SSRC is found in the incoming SSRC table, deliver a copy whose SSRC is found in the incoming SSRC table, deliver a copy
of the SDES packet to the "m=" section associated with that SSRC . of the SDES packet to the "m=" section associated with that SSRC .
In addition, for any SDES MID items contained in these chunks, In addition, for any SDES MID items contained in these chunks,
if the MID is found in the table mapping MID to "m=" section, if the MID is found in the table mapping a MID to an "m=" sectio n,
update the incoming SSRC table to include an entry that update the incoming SSRC table to include an entry that
maps the RTP stream associated with the chunk's SSRC to the "m=" section maps the RTP stream associated with the chunk's SSRC to the "m=" section
associated with that MID, unless the packet is older than the pa cket associated with that MID, unless the packet is older than the pa cket
that most recently updated the mapping for this SSRC, as discuss ed in that most recently updated the mapping for this SSRC, as discuss ed in
<xref target="RFC7941"/>, Section 4.2.6. <xref target="RFC7941" sectionFormat="comma" section="4.2.6"/>.
</t> </li>
<t> <li>
Note that if an SDES packet is received as part of a compound RT CP Note that if an SDES packet is received as part of a compound RT CP
packet, the SSRC to "m=" section mapping might not exist until t he packet, the SSRC to "m=" section mapping might not exist until t he
SDES packet is handled (e.g., in the case where RTCP for a sourc e SDES packet is handled (e.g., in the case where RTCP for a sourc e
is received before any RTP packets). Therefore, it can be benefi cial is received before any RTP packets). Therefore, it can be benefi cial
for an implementation to delay RTCP packet routing, such that it for an implementation to delay RTCP packet routing, such that it
either prioritizes processing of the SDES item to generate or up date either prioritizes processing of the SDES item to generate or up date
the mapping, or buffers the RTCP information that needs to be the mapping or buffers the RTCP information that needs to be
routed until the SDES item(s) has been processed. If the routed until the SDES item(s) has been processed. If the
implementation is unable to follow this recommendation, the implementation is unable to follow this recommendation, the
consequence could be that some RTCP information from this consequence could be that some RTCP information from this
particular RTCP compound packet is not provided to higher layers . particular RTCP compound packet is not provided to higher layers .
The impact from this is likely minor, when this information rela tes The impact from this is likely minor, when this information rela tes
to a future incoming RTP stream. to a future incoming RTP stream.
</t> </li>
<t> <li>
If the RTCP packet is of type BYE, it indicates that the RTP str eams If the RTCP packet is of type BYE, it indicates that the RTP str eams
referenced in the packet are ending. Therefore, for each SSRC referenced in the packet are ending. Therefore, for each SSRC
indicated in the packet that is found in the incoming SSRC table , indicated in the packet that is found in the incoming SSRC table ,
first deliver a copy of the BYE packet to the "m=" section assoc iated first deliver a copy of the BYE packet to the "m=" section assoc iated
with that SSRC, then remove the entry for that SSRC from the with that SSRC, and then remove the entry for that SSRC from the
incoming SSRC table after an appropriate delay to incoming SSRC table after an appropriate delay to
account for "straggler packets", as specified in <xref account for "straggler packets", as specified in <xref target="R
target="RFC3550" />, Section 6.2.1. FC3550" sectionFormat="comma" section="6.2.1"/>.
</t> </li>
<t> <li>
If the RTCP packet is of type SR or RR, for each report block in If the RTCP packet is of type Sender Report (SR) or Receiver Rep
ort (RR), for each report block in
the report whose "SSRC of source" is found in the outgoing the report whose "SSRC of source" is found in the outgoing
SSRC table, deliver a copy of the SR or RR packet to the "m=" se ction SSRC table, deliver a copy of the SR or RR packet to the "m=" se ction
associated with that SSRC. In addition, if the packet is of type associated with that SSRC. In addition, if the packet is of type
SR, and the sender SSRC for the packet is found in the SR, and the sender SSRC for the packet is found in the
incoming SSRC table, deliver a copy of the SR packet to the "m=" section incoming SSRC table, deliver a copy of the SR packet to the "m=" section
associated with that SSRC. associated with that SSRC.
</t> </li>
<t> <li>
If the implementation supports RTCP XR and the packet is of If the implementation supports the RTCP Extended Report (XR) and
type XR, as defined in <xref target="RFC3611" />, the packet is of
type XR, as defined in <xref target="RFC3611" format="default"/>
,
for each report block in the report whose "SSRC of source" for each report block in the report whose "SSRC of source"
is found in the outgoing SSRC table, deliver a copy of the is found in the outgoing SSRC table, deliver a copy of the
XR packet to the "m=" section associated with that SSRC. XR packet to the "m=" section associated with that SSRC.
In addition, if the sender SSRC for the packet is found in the In addition, if the sender SSRC for the packet is found in the
incoming SSRC table, deliver a copy of the XR packet to the "m=" section incoming SSRC table, deliver a copy of the XR packet to the "m=" section
associated with that SSRC. associated with that SSRC.
</t> </li>
<t> <li>
If the RTCP packet is a feedback message of type RTPFB or PSFB, If the RTCP packet is a feedback message of type RTPFB (transpor
as defined in <xref target="RFC4585" />, it will contain a t-layer FB
message) or PSFB (payload-specific FB message),
as defined in <xref target="RFC4585" format="default"/>, it will
contain a
media source SSRC, and this SSRC is used for routing certain media source SSRC, and this SSRC is used for routing certain
subtypes of feedback messages. However, several subtypes of subtypes of feedback messages. However, several subtypes of
PSFB and RTPFB messages include target SSRC(s) in a section call ed PSFB and RTPFB messages include a target SSRC(s) in a section ca lled
Feedback Control Information (FCI). For these messages, Feedback Control Information (FCI). For these messages,
the target SSRC(s) are used for routing. the target SSRC(s) is used for routing.
</t> </li>
<li>
<t> <t>
If the RTCP packet is a feedback packet that does not include If the RTCP packet is a feedback packet that does not include
target SSRCs in its FCI section, and the media source SSRC is target SSRCs in its FCI section, and the media source SSRC is
found in the outgoing SSRC table, deliver the found in the outgoing SSRC table, deliver the
feedback packet to the "m=" section associated with that SSRC. feedback packet to the "m=" section associated with that SSRC.
RTPFB and PSFB types that are handled in this way include: RTPFB and PSFB types that are handled in this way include:
<list style="hanging">
<t hangText="Generic NACK:">
<xref target="RFC4585"/> (PT=RTPFB, FMT=1).
</t>
<t hangText="Picture Loss Indication (PLI):">
<xref target="RFC4585"/> (PT=PSFB, FMT=1).
</t>
<t hangText="Slice Loss Indication (SLI):">
<xref target="RFC4585"/> (PT=PSFB, FMT=2).
</t>
<t hangText="Reference Picture Selection Indication (RPSI):"
>
<xref target="RFC4585"/> (PT=PSFB, FMT=3).
</t>
</list>
</t> </t>
<t> <ul empty="true"><li>
If the RTCP packet is a feedback message that does include targe <dl newline="false" spacing="normal">
t <dt>Generic NACK:</dt>
<dd>(PT=RTPFB, FMT=1) <xref target="RFC4585" format="default"/>.</
dd>
<dt>Picture Loss Indication (PLI):</dt>
<dd>(PT=PSFB, FMT=1) <xref target="RFC4585" format="default"/>.</d
d>
<dt>Slice Loss Indication (SLI):</dt>
<dd> (PT=PSFB, FMT=2) <xref target="RFC4585" format="default"/>.</
dd>
<dt>Reference Picture Selection Indication (RPSI):</dt>
<dd>(PT=PSFB, FMT=3) <xref target="RFC4585" format="default"/>.</d
d>
</dl>
</li>
</ul></li></ul>
<ul empty="false">
<li>
If the RTCP packet is a feedback message that does include a tar
get
SSRC(s) in its FCI section, it can either be a request or a SSRC(s) in its FCI section, it can either be a request or a
notification. Requests reference a RTP stream that is being notification. Requests reference an RTP stream that is being
sent by the message recipient, whereas notifications are respons es sent by the message recipient, whereas notifications are respons es
to an earlier request, and therefore reference a RTP stream that to an earlier request and therefore reference an RTP stream that
is being received by the message recipient. is being received by the message recipient.
</t> </li>
<li>
<t> <t>
If the RTCP packet is a feedback request that includes target SS RC(s), If the RTCP packet is a feedback request that includes a target SSRC(s),
for each target SSRC that is found in the outgoing SSRC table, for each target SSRC that is found in the outgoing SSRC table,
deliver a copy of the RTCP packet to the "m=" section associated with deliver a copy of the RTCP packet to the "m=" section associated with
that SSRC. PSFB and RTPFB types that are handled in this way inc lude: that SSRC. PSFB and RTPFB types that are handled in this way inc lude:
<list style="hanging">
<t hangText="Full Intra Request (FIR):">
<xref target="RFC5104"/> (PT=PSFB, FMT=4).
</t>
<t hangText="Temporal-Spatial Trade-off Request (TSTR):">
<xref target="RFC5104"/> (PT=PSFB, FMT=5).
</t>
<t hangText="H.271 Video Back Channel Message (VBCM):">
<xref target="RFC5104"/> (PT=PSFB, FMT=7).
</t>
<t hangText="Temporary Maximum Media Bit Rate Request (TMMBR
):">
<xref target="RFC5104"/> (PT=RTPFB, FMT=3).
</t>
<t hangText="Layer Refresh Request (LRR):">
<xref target="I-D.ietf-avtext-lrr"/> (PT=PSFB, FMT=10).
</t>
</list>
</t> </t>
<t> <ul empty="true"><li>
If the RTCP packet is a feedback notification that includes targ <dl newline="false" spacing="normal">
et SSRC(s), <dt>Full Intra Request (FIR):</dt>
<dd>(PT=PSFB, FMT=4) <xref target="RFC5104" format="default"/>.
</dd>
<dt>Temporal-Spatial Trade-off Request (TSTR):</dt>
<dd>(PT=PSFB, FMT=5) <xref target="RFC5104" format="default"/>.
</dd>
<dt>H.271 Video Back Channel Message (VBCM):</dt>
<dd>(PT=PSFB, FMT=7) <xref target="RFC5104" format="default"/>.
</dd>
<dt>Temporary Maximum Media Stream Bit Rate Request (TMMBR):</dt>
<dd>(PT=RTPFB, FMT=3) <xref target="RFC5104" format="default"/>.
</dd>
<dt>Layer Refresh Request (LRR):</dt>
<dd>(PT=PSFB, FMT=10) <xref target="I-D.ietf-avtext-lrr" format="d
efault"/>.
</dd>
</dl>
</li></ul></li></ul>
<ul empty="false"><li>
<t>
If the RTCP packet is a feedback notification that includes a ta
rget SSRC(s),
for each target SSRC that is found in the incoming SSRC table, for each target SSRC that is found in the incoming SSRC table,
deliver a copy of the RTCP packet to the "m=" section associated with deliver a copy of the RTCP packet to the "m=" section associated with
the RTP stream with matching SSRC. PSFB and RTPFB types that are the RTP stream with a matching SSRC. PSFB and RTPFB types that a
handled in this way include: re handled in this way include:
<list style="hanging"> </t>
<t hangText="Temporal-Spatial Trade-off Notification (TSTN):
"> <ul empty="true"><li>
<xref target="RFC5104"/> (PT=PSFB, FMT=6). This message <dl newline="false" spacing="normal">
<dt>Temporal-Spatial Trade-off Notification (TSTN):</dt>
<dd>(PT=PSFB, FMT=6) <xref target="RFC5104" format="default"/>. Th
is message
is a notification in response to a prior TSTR. is a notification in response to a prior TSTR.
</t> </dd>
<t hangText="Temporary Maximum Media Bit Rate Notification ( <dt>Temporary Maximum Media Stream Bit Rate Notification (TMMBN):<
TMMBN):"> /dt>
<xref target="RFC5104"/> (PT=RTPFB, FMT=4). This message <dd>(PT=RTPFB, FMT=4) <xref target="RFC5104" format="default"/>. T
is a his message is a
notification in response to a prior TMMBR, but can also notification in response to a prior TMMBR, but it can al
be sent so be sent
unsolicited. unsolicited.
</t> </dd>
</list> </dl>
</t> </li></ul></li></ul>
<t>
If the RTCP packet is of type APP, then it is handled in an applic
ation
specific manner. If the application does not recognise the APP pac
ket,
then it MUST be discarded.
</t>
</list>
</t>
</section>
<section title="RTP/RTCP Multiplexing" anchor="sec-rtprtcp-mux" toc="default <ul empty="true">
"> <li>
If the RTCP packet is of type APP, then it is handled in an applic
ation-specific
manner. If the application does not recognize the APP packet,
then it <bcp14>MUST</bcp14> be discarded.
</li>
</ul>
</section>
<section anchor="sec-rtprtcp-mux" toc="default" numbered="true">
<name>RTP/RTCP Multiplexing</name>
<t> <t>
Within a BUNDLE group, the offerer and answerer MUST enable Within a BUNDLE group, the offerer and answerer <bcp14>MUST</bcp14> en
RTP/RTCP multiplexing <xref format="default" pageno="false" able
target="RFC5761"/> for the RTP-based bundled media (i.e., the RTP/RTCP multiplexing <xref format="default" target="RFC5761"/> for th
e RTP-based bundled media (i.e., the
same transport will be used for both RTP packets and RTCP packets). same transport will be used for both RTP packets and RTCP packets).
In addition, the offerer and answerer MUST support the In addition, the offerer and answerer <bcp14>MUST</bcp14> support the
SDP 'rtcp-mux-only' attribute <xref format="default" pageno="false" SDP 'rtcp-mux-only' attribute <xref format="default" target="RFC8858"/
target="I-D.ietf-mmusic-mux-exclusive"/>. >.
</t> </t>
<section title="SDP Offer/Answer Procedures" anchor="sec-rtprtcp-mux-oa" <section anchor="sec-rtprtcp-mux-oa" toc="default" numbered="true">
toc="default"> <name>SDP Offer/Answer Procedures</name>
<t> <t>
This section describes how an offerer and answerer use the This section describes how an offerer and answerer use the
SDP 'rtcp-mux' attribute <xref format="default" pageno="false" SDP 'rtcp-mux' <xref format="default" target="RFC5761"/> and SDP 'rt
target="RFC5761"/> and the SDP 'rtcp-mux-only' attribute cp-mux-only' attributes
<xref format="default" pageno="false" target="I-D.ietf-mmusic-mux-ex <xref format="default" target="RFC8858"/>
clusive"/>
to negotiate usage of RTP/RTCP multiplexing for RTP-based bundled me dia. to negotiate usage of RTP/RTCP multiplexing for RTP-based bundled me dia.
</t> </t>
<t> <t>
RTP/RTCP multiplexing only applies to RTP-based media. However, as d escribed in RTP/RTCP multiplexing only applies to RTP-based media. However, as d escribed in
<xref format="default" pageno="false" target="sec-sdp-oa-cat"/>, wit hin an offer <xref format="default" target="sec-sdp-oa-cat"/>, within an offer
or answer the SDP 'rtcp-mux' and SDP 'rtcp-mux-only' attributes migh t be included in or answer the SDP 'rtcp-mux' and SDP 'rtcp-mux-only' attributes migh t be included in
a bundled "m=" section for non-RTP-based media (if such "m=" section a bundled "m=" section for non-RTP-based media (if such "m=" section
is the offerer is the offerer-tagged
tagged "m=" section or answerer tagged "m=" section). "m=" section or answerer-tagged "m=" section).
</t> </t>
<section title="Generating the Initial SDP BUNDLE Offer" anchor="sec-rtp <section anchor="sec-rtprtcp-mux-oa-ino" toc="default" numbered="true"
rtcp-mux-oa-ino" toc="default"> >
<t> <name>Generating the Initial SDP BUNDLE Offer</name>
<t>
When an offerer generates an initial BUNDLE offer, if the offer cont ains When an offerer generates an initial BUNDLE offer, if the offer cont ains
one or more bundled "m=" sections for RTP-based media (or, if there is a chance that "m=" sections one or more bundled "m=" sections for RTP-based media (or, if there is a chance that "m=" sections
for RTP-based media will later be added to the BUNDLE group), the of for RTP-based media will later be added to the BUNDLE group), the of
ferer MUST ferer <bcp14>MUST</bcp14>
include an SDP 'rtcp-mux' attribute <xref format="default" pageno="f include an SDP 'rtcp-mux' attribute <xref format="default" target="R
alse" target="RFC5761"/> in each FC5761"/> in each
bundled "m=" section (excluding any bundle-only "m=" sections). In a bundled "m=" section (excluding any bundle-only "m=" sections). In a
ddition, the offerer MAY include an ddition, the offerer <bcp14>MAY</bcp14> include an
SDP 'rtcp-mux-only' attribute <xref format="default" pageno="false" SDP 'rtcp-mux-only' attribute <xref format="default" target="RFC8858
target="I-D.ietf-mmusic-mux-exclusive"/> "/>
in one or more bundled "m=" sections for RTP-based media. in one or more bundled "m=" sections for RTP-based media.
</t> </t>
<t> <t>
NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute
depends on whether the offerer supports fallback to usage of a separ ate depends on whether the offerer supports fallback to usage of a separ ate
port for RTCP in case the answerer moves one or more "m=" sections f or RTP-based media port for RTCP in case the answerer moves one or more "m=" sections f or RTP-based media
out of the BUNDLE group in the answer. out of the BUNDLE group in the answer.
</t> </t>
<t> <t>
NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the bun dled "m=" sections, NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the bun dled "m=" sections,
but does not include an SDP 'rtcp-mux-only' attribute, but does not include an SDP 'rtcp-mux-only' attribute,
the offerer can also include an SDP 'rtcp' attribute <xref format="d the offerer can also include an SDP 'rtcp' attribute <xref format="d
efault" efault" target="RFC3605"/> in one or more RTP-based bundled "m=" sections in ord
pageno="false" target="RFC3605"/> in one or more RTP-based bundled " er
m=" sections in order to provide a fallback port for RTCP, as described in <xref format="d
to provide a fallback port for RTCP, as described in <xref format="d efault" target="RFC5761"/>. However, the fallback port will only be applied to "
efault" pageno="false" m=" sections for RTP-based
target="RFC5761"/>. However, the fallback port will only be applied
to "m=" sections for RTP-based
media that are moved out of the BUNDLE group by the answerer. media that are moved out of the BUNDLE group by the answerer.
</t> </t>
<t> <t>
In the initial BUNDLE offer, the address:port combination for RTCP M In the initial BUNDLE offer, the address:port combination for RTCP <
UST be unique in each bcp14>MUST</bcp14> be unique in each
bundled "m=" section for RTP-based media (excluding a bundle-only "m =" section), similar to RTP. bundled "m=" section for RTP-based media (excluding a bundle-only "m =" section), similar to RTP.
</t> </t>
</section> </section>
<section title="Generating the SDP Answer" anchor="sec-rtprtcp-mux-oa-an <section anchor="sec-rtprtcp-mux-oa-ans" toc="default" numbered="true"
s" toc="default"> >
<t> <name>Generating the SDP Answer</name>
<t>
When an answerer generates an answer, if the answerer supports RTP-b ased media, When an answerer generates an answer, if the answerer supports RTP-b ased media,
and if a bundled "m=" section in the corresponding offer contained a n SDP 'rtcp-mux' attribute, and if a bundled "m=" section in the corresponding offer contained a n SDP 'rtcp-mux' attribute,
the answerer MUST enable usage of RTP/RTCP multiplexing, even if the the answerer <bcp14>MUST</bcp14> enable usage of RTP/RTCP multiplexi
re currently ng, even if there currently
are no bundled "m=" sections for RTP-based media within the BUNDLE g are no bundled "m=" sections for RTP-based media within the BUNDLE g
roup. The answerer MUST include roup. The answerer <bcp14>MUST</bcp14> include
an SDP 'rtcp-mux' attribute in the answerer tagged "m=" section, fol an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" section, fol
lowing the procedures for lowing the procedures for
BUNDLE attributes [<xref format="default" pageno="false" target="sec BUNDLE attributes (<xref format="default" target="sec-sdp-oa-cat"/>)
-sdp-oa-cat"/>]. .
In addition, if the "m=" section that is selected as the offerer tag In addition, if the "m=" section that is selected as the offerer-tag
ged "m=" section contained ged "m=" section contained
an SDP "rtcp-mux-only" attribute, the answerer MUST include an SDP " an SDP 'rtcp-mux-only' attribute, the answerer <bcp14>MUST</bcp14> i
rtcp-mux-only" attribute nclude an SDP 'rtcp-mux-only' attribute
in the answerer tagged "m=" section. in the answerer-tagged "m=" section.
</t> </t>
<t>
In an initial BUNDLE offer, if the suggested offerer tagged "m=" sec <!-- [rfced] In this document, SDP attribute names are sometimes in single
tion contained an quotes and other times in double quotes. Would you like to make these
SDP 'rtcp-mux-only' attribute, the "m=" section was for RTP-based me consistently double quotes? For example (both in Section 9.3.1.2):
dia, and the
answerer does not accept the "m=" section in the created BUNDLE grou an SDP "rtcp-mux-only" attribute
p, the answerer an SDP 'rtcp' attribute
MUST either move the "m=" section out of the BUNDLE group [<xref for -->
mat="default"
pageno="false" target="sec-sdp-oa-ans-mov"/>], include the attribute <t>
in the In an initial BUNDLE offer, if the suggested offerer-tagged "m=" sec
tion contained an
SDP 'rtcp-mux-only' attribute, the "m=" section was for RTP-based me
dia; thus, the
answerer does not accept the "m=" section in the created BUNDLE grou
p, and the answerer
<bcp14>MUST</bcp14> move the "m=" section out of the BUNDLE group (<
xref format="default" target="sec-sdp-oa-ans-mov"/>); include the attribute in t
he
moved "m=" section and enable RTP/RTCP multiplexing for the media as sociated with moved "m=" section and enable RTP/RTCP multiplexing for the media as sociated with
the "m=" section, or reject the "m=" section [<xref format="default" the "m=" section; or reject the "m=" section (<xref format="default"
pageno="false" target="sec-sdp-oa-ans-rej"/>).
target="sec-sdp-oa-ans-rej"/>]. </t>
</t> <t>
<t> The answerer <bcp14>MUST NOT</bcp14> include an SDP 'rtcp' attribute
The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled in any bundled "m=" section
"m=" section in the answer. The answerer will use the port value of the offerer-t
in the answer. The answerer will use the port value of the tagged of agged
ferer
"m=" section sending RTP and RTCP packets associated with RTP-based bundled media "m=" section sending RTP and RTCP packets associated with RTP-based bundled media
towards the offerer. towards the offerer.
</t> </t>
<t> <t>
If the usage of RTP/RTCP multiplexing within a BUNDLE group has been If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
negotiated in a previous offer/answer exchange, the answerer MUST negotiated in a previous offer/answer exchange, the answerer <bcp14>
include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" sect MUST</bcp14>
ion . include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" sect
ion.
It is not possible to disable RTP/RTCP multiplexing within a BUNDLE group. It is not possible to disable RTP/RTCP multiplexing within a BUNDLE group.
</t> </t>
</section> </section>
<section title="Offerer Processing of the SDP Answer" anchor="sec-rtprtc <section anchor="sec-rtprtcp-mux-oa-pra" toc="default" numbered="true"
p-mux-oa-pra" toc="default"> >
<t> <name>Offerer Processing of the SDP Answer</name>
<t>
When an offerer receives an answer, if the answerer has accepted When an offerer receives an answer, if the answerer has accepted
the usage of RTP/RTCP multiplexing [<xref target="sec-rtprtcp-mux-oa -ans"/>], the usage of RTP/RTCP multiplexing (<xref target="sec-rtprtcp-mux-oa -ans" format="default"/>),
the answerer follows the procedures for RTP/RTCP multiplexing define d the answerer follows the procedures for RTP/RTCP multiplexing define d
in <xref format="default" pageno="false" target="RFC5761"/>. The in <xref format="default" target="RFC5761"/>. The
offerer will use the port value of the answerer tagged "m=" section offerer will use the port value of the answerer-tagged "m=" section
for sending RTP and RTCP packets associated with for sending RTP and RTCP packets associated with
RTP-based bundled media towards the answerer. RTP-based bundled media towards the answerer.
</t> </t>
<t> <t>
NOTE: It is considered a protocol error if the answerer has not NOTE: It is considered a protocol error if the answerer has not
accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" secti ons accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" secti ons
that the answerer included in the BUNDLE group. that the answerer included in the BUNDLE group.
</t> </t>
</section> </section>
<section title="Modifying the Session" anchor="sec-rtprtcp-mux-oa-mod" t <section anchor="sec-rtprtcp-mux-oa-mod" toc="default" numbered="true"
oc="default"> >
<t> <name>Modifying the Session</name>
When an offerer generates a subsequent offer, the offerer MUST inclu <t>
de When an offerer generates a subsequent offer, the offerer <bcp14>MUS
an SDP 'rtcp-mux' attribute in the offerer tagged "m=" section, foll T</bcp14> include
owing an SDP 'rtcp-mux' attribute in the offerer-tagged "m=" section, foll
owing
the procedures for IDENTICAL multiplexing category attributes in the procedures for IDENTICAL multiplexing category attributes in
<xref format="default" pageno="false" target="sec-sdp-oa-cat"/>. <xref format="default" target="sec-sdp-oa-cat"/>.
</t> </t>
</section>
</section> </section>
</section> </section>
</section> </section>
</section> <section anchor="sec-ice" toc="default" numbered="true">
<name>ICE Considerations</name>
<section title="ICE Considerations" anchor="sec-ice" toc="default">
<t> <t>
This section describes how to use the BUNDLE grouping extension together This section describes how to use the BUNDLE grouping extension together
with the Interactive Connectivity Establishment (ICE) mechanism <xref with the ICE mechanism <xref format="default" target="RFC8445"/>.
format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/>.
</t> </t>
<t> <t>
The generic procedures for negotiating usage of ICE using SDP, defined The generic procedures for negotiating the usage of ICE using SDP, defin
in <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>, also apply to usage of ed
ICE in <xref target="RFC8839" format="default"/>, also apply to the usage of
ICE
with BUNDLE, with the following exceptions: with BUNDLE, with the following exceptions:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t> When the BUNDLE transport has been established, ICE connectivity che
When the BUNDLE transport has been established, ICE connectivity che cks and keepalives
cks and keep-alives
only need to be performed for the BUNDLE transport, instead of per i ndividual bundled "m=" section only need to be performed for the BUNDLE transport, instead of per i ndividual bundled "m=" section
within the BUNDLE group. within the BUNDLE group.
</t> </li>
<t> <li>
The generic SDP attribute offer/answer considerations [<xref format= The generic SDP attribute offer/answer considerations (<xref format=
"default" pageno="false" target="sec-sdp-oa-cat"/>] also apply to ICE-related "default" target="sec-sdp-oa-cat"/>) also apply to ICE-related
attributes. Therefore, when an offer sends an initial BUNDLE offer ( attributes. Therefore, when an offerer sends an initial BUNDLE offer
in order to negotiate a BUNDLE group) the offerer (in order to negotiate a BUNDLE group), the offerer
include ICE-related media-level attributes in each bundled "m=" sect includes ICE-related media-level attributes in each bundled "m=" sec
ion (excluding any bundle-only "m=" section), tion (excluding any bundle-only "m=" sections),
and each "m=" section MUST contain unique ICE properties. When an an and each "m=" section <bcp14>MUST</bcp14> contain unique ICE propert
swerer generates an answer (initial BUNDLE answer or subsequent) ies. When an answerer generates an answer (initial BUNDLE answer or subsequent)
that contains a BUNDLE group, and when an offerer sends a subsequent offer that contains a BUNDLE group, ICE-related media-level that contains a BUNDLE group, and when an offerer sends a subsequent offer that contains a BUNDLE group, ICE-related media-level
attributes are only included in the tagged "m=" section (suggested o fferer tagged "m=" section or answerer tagged "m=" section), and attributes are only included in the tagged "m=" section (suggested o fferer-tagged "m=" section or answerer-tagged "m=" section), and
the ICE properties are applied to each bundled "m=" section within t he BUNDLE group. the ICE properties are applied to each bundled "m=" section within t he BUNDLE group.
</t> </li>
</list> </ul>
</t>
<t> <t>
NOTE: Most ICE-related media-level SDP attributes belong to the TRANSPOR T multiplexing category NOTE: Most ICE-related media-level SDP attributes belong to the TRANSPOR T multiplexing category
<xref target="I-D.ietf-mmusic-sdp-mux-attributes" />, and the generic SD <xref target="RFC8859" format="default"/>, and the generic SDP attribute
P attribute offer/answer offer/answer
considerations for TRANSPORT multiplexing category apply to the attribut considerations for the TRANSPORT multiplexing category apply to the attr
es. However, in the case of ibutes. However, in the case of
ICE-related attributes, the same considerations also apply to ICE-relate d media-level attributes that ICE-related attributes, the same considerations also apply to ICE-relate d media-level attributes that
belong to other multiplexing categories. belong to other multiplexing categories.
</t> </t>
<t> <t>
NOTE: The following ICE-related media-level SDP attributes are defined i n NOTE: The following ICE-related media-level SDP attributes are defined i n
<xref target="I-D.ietf-mmusic-ice-sip-sdp" />: 'candidate', 'remote-cand idates', 'ice-mismatch', <xref target="RFC8839" format="default"/>: 'candidate', 'remote-candidat es', 'ice-mismatch',
'ice-ufrag', 'ice-pwd', and 'ice-pacing'. 'ice-ufrag', 'ice-pwd', and 'ice-pacing'.
</t> </t>
<t> <t>
Initially, before ICE has produced selected candidate pairs that will be used for media, there might Initially, before ICE has produced selected candidate pairs that will be used for media, there might
be multiple transports established (if multiple candidate pairs are test ed). Once ICE has selected be multiple transports established (if multiple candidate pairs are test ed). Once ICE has selected
candidate pairs, they form the BUNDLE transport. candidate pairs, they form the BUNDLE transport.
</t> </t>
<t> <t>
Support and usage of ICE mechanism together with the BUNDLE extension Support and usage of the ICE mechanism together with the BUNDLE extensio
is OPTIONAL, and the procedures in this section only apply when the n
is <bcp14>OPTIONAL</bcp14>, and the procedures in this section only appl
y when the
ICE mechanism is used. Note that applications might mandate usage ICE mechanism is used. Note that applications might mandate usage
of the ICE mechanism even if the BUNDLE extension is not used. of the ICE mechanism even if the BUNDLE extension is not used.
</t> </t>
<t> <t>
NOTE: If the trickle ICE mechanism <xref target="I-D.ietf-mmusic-trickle NOTE: If the Trickle ICE mechanism <xref target="RFC8840" format="defaul
-ice-sip" /> t"/>
is used, an offerer and answerer might assign a port value of '9', and a is used, an offerer and answerer might assign a port value of '9' and an
n IPv4 IPv4
address of '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" sections address of '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" sections
in the initial BUNDLE offer. The offerer and answerer will follow the no rmal procedures in the initial BUNDLE offer. The offerer and answerer will follow the no rmal procedures
for generating the offers and answers, including picking a bundled "m=" section as the for generating the offers and answers, including picking a bundled "m=" section as the
suggested offerer tagged "m=" section, selecting the tagged "m=" section suggested offerer-tagged "m=" section, selecting the tagged "m=" section
s etc. The only s, etc. The only
difference is that media can not be sent until one or more candidates ha difference is that media cannot be sent until one or more candidates hav
ve been provided. e been provided.
Once a BUNDLE group has been negotiated, trickled candidates associated with a bundled Once a BUNDLE group has been negotiated, trickled candidates associated with a bundled
"m=" section will be applied to all bundled "m=" sections within the BUN DLE group. "m=" section will be applied to all bundled "m=" sections within the BUN DLE group.
</t> </t>
</section> </section>
<section anchor="sec-dtls" toc="default" numbered="true">
<section title="DTLS Considerations" anchor="sec-dtls" toc="default"> <name>DTLS Considerations</name>
<t> <t>
One or more media streams within a BUNDLE group might use One or more media streams within a BUNDLE group might use
the Datagram Transport Layer Security (DTLS) protocol the Datagram Transport Layer Security (DTLS) protocol
<xref format="default" pageno="false" target="RFC6347"/> <xref format="default" target="RFC6347"/>
in order to encrypt the data, or to negotiate encryption keys in order to encrypt the data or negotiate encryption keys
if another encryption mechanism is used to encrypt media. if another encryption mechanism is used to encrypt media.
</t> </t>
<t> <t>
When DTLS is used within a BUNDLE group, the following rules When DTLS is used within a BUNDLE group, the following rules
apply: apply:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
There can only be one DTLS association There can only be one DTLS association
<xref format="default" pageno="false" target="RFC6347"/> <xref format="default" target="RFC6347"/>
associated with the BUNDLE group; and associated with the BUNDLE group;
</t> </li>
<t> <li>
Each usage of the DTLS association within the BUNDLE Each usage of the DTLS association within the BUNDLE
group MUST use the same mechanism for determining group <bcp14>MUST</bcp14> use the same mechanism for determining
which endpoints (the offerer or answerer) become which endpoints (the offerer or answerer) become
DTLS client and DTLS server; and DTLS client and DTLS server;
</t> </li>
<t> <li>
Each usage of the DTLS association within the BUNDLE Each usage of the DTLS association within the BUNDLE
group MUST use the same mechanism for determining group <bcp14>MUST</bcp14> use the same mechanism for determining
whether an offer or answer will trigger the whether an offer or answer will trigger the
establishment of a new DTLS association, or whether establishment of a new DTLS association or
an existing DTLS association will be used; and an existing DTLS association will be used; and
</t> </li>
<t>
If the DTLS client supports DTLS-SRTP <li>
<xref format="default" pageno="false" target="RFC5764"/> If the DTLS client supports DTLS-SRTP,
it MUST include the 'use_srtp' extension it <bcp14>MUST</bcp14> include the 'use_srtp' extension
<xref format="default" pageno="false" target="RFC5764"/>
in the DTLS ClientHello message in the DTLS ClientHello message
<xref format="default" pageno="false" target="RFC5764"/>. <xref format="default" target="RFC5764"/>.
The client MUST include the extension even if the usage The client <bcp14>MUST</bcp14> include the extension even if the usage
of DTLS-SRTP is not negotiated as part of the of DTLS-SRTP is not negotiated as part of the
multimedia session (e.g., SIP session <xref format="default" multimedia session (e.g., the SIP session <xref format="default" targe
pageno="false" target="RFC3261"/>). t="RFC3261"/>).
</t> </li>
</list> </ul>
</t>
<t> <t>
NOTE: The inclusion of the 'use_srtp' extension during the initial NOTE: The inclusion of the 'use_srtp' extension during the initial
DTLS handshake ensures that a DTLS renegotiation will not be required DTLS handshake ensures that a DTLS renegotiation will not be required
in order to include the extension, in case DTLS-SRTP encrypted media in order to include the extension, in case DTLS-SRTP encrypted media
is added to the BUNDLE group later during the multimedia session. is added to the BUNDLE group later during the multimedia session.
</t> </t>
</section> </section>
<section anchor="sec-extmap" toc="default" numbered="true">
<section title="RTP Header Extensions Consideration" anchor="sec-extmap" toc <name>RTP Header Extensions Consideration</name>
="default"> <t>When RTP header extensions <xref target="RFC8285" format="default"/> ar
<t>When <xref target="RFC8285"/> RTP header extensions are used in the con e used in the context of this
text of this specification, the identifier used for a given extension <bcp14>MUST</bcp
specification, the identifier used for a given extension MUST identify th 14> identify the same
e same
extension across all the bundled media descriptions. </t> extension across all the bundled media descriptions. </t>
</section> </section>
<section anchor="sec-3264" title="Update to RFC 3264" toc="default"> <section anchor="sec-3264" toc="default" numbered="true">
<name>Update to RFC 3264</name>
<t> <t>
This section updates RFC 3264, in order to allow extensions to define th e usage of This section updates RFC 3264, in order to allow extensions to define th e usage of
a zero port value in offers and answers for other purposes than removing a zero port value in offers and answers for purposes other than removing
or disabling or disabling
media streams. The following sections of RFC 3264 are updated: media streams. The following sections are being updated:
</t>
<t>
<list style="symbols">
<t>Section 5.1 (Unicast Streams).</t>
<t>Section 8.4 (Putting a Unicast Media Stream on Hold).</t>
</list>
</t> </t>
<section anchor="sec-3264-old-5_1" title="Original text of section 5.1 (2nd <ul spacing="normal">
paragraph) of RFC 3264" toc="default"> <li>"Unicast Streams"; see <xref target="RFC3264" sectionFormat="of" sec
<t> tion="5.1"/></li>
<li>"Putting a Unicast Media Stream on Hold"; see <xref target="RFC3264"
sectionFormat="of" section="8.4"/>. </li>
</ul>
<section anchor="sec-3264-old-5_1" toc="default" numbered="true">
<name>Original Text from RFC 3264, Section 5.1, 2nd Paragraph</name>
<blockquote>
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
and port present in the offer indicate nothing about the source IP and port present in the offer indicate nothing about the source IP
address and source port of RTP and RTCP packets that will be sent by address and source port of RTP and RTCP packets that will be sent by
the offerer. A port number of zero in the offer indicates that the the offerer. A port number of zero in the offer indicates that the
stream is offered but MUST NOT be used. This has no useful semantics stream is offered but <bcp14>MUST NOT</bcp14> be used. This has no usef ul semantics
in an initial offer, but is allowed for reasons of completeness, in an initial offer, but is allowed for reasons of completeness,
since the answer can contain a zero port indicating a rejected stream since the answer can contain a zero port indicating a rejected stream
(Section 6). Furthermore, existing streams can be terminated by (Section 6). Furthermore, existing streams can be terminated by
setting the port to zero (Section 8). In general, a port number of setting the port to zero (Section 8). In general, a port number of
zero indicates that the media stream is not wanted. zero indicates that the media stream is not wanted.
</t> </blockquote>
</section> </section>
<section anchor="sec-3264-new-5_1" title="New text replacing section 5.1 (2n <section anchor="sec-3264-new-5_1" toc="default" numbered="true">
d paragraph) of RFC 3264" toc="default"> <name>New Text Replacing RFC 3264, Section 5.1, 2nd Paragraph</name>
<t> <t>
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
and port present in the offer indicate nothing about the source IP and port present in the offer indicate nothing about the source IP
address and source port of RTP and RTCP packets that will be sent by address and source port of the RTP and RTCP packets that will be sent by
the offerer. A port number of zero in the offer by default indicates tha the offerer. By default, a port number of zero in the offer indicates th
t the at the
stream is offered but MUST NOT be used, but an extension mechanism stream is offered but <bcp14>MUST NOT</bcp14> be used, but an extension
mechanism
might specify different semantics for the usage of a zero port value. might specify different semantics for the usage of a zero port value.
Furthermore, existing streams can be terminated by setting the port to Furthermore, existing streams can be terminated by setting the port to
zero (Section 8). In general, a port number of zero by default indicates zero (Section 8). In general, a port number of zero by default indicates
that the media stream is not wanted. that the media stream is not wanted.
</t> </t>
</section> </section>
<section anchor="sec-3264-old-8_4" title="Original text of section 8.4 (6th <section anchor="sec-3264-old-8_4" toc="default" numbered="true">
paragraph) of RFC 3264" toc="default"> <name>Original Text from RFC 3264, Section 8.4, 6th Paragraph</name>
<t>
RFC 2543 [10] specified that placing a user on hold was accomplished <!--Note: Updated 'is to' to 'should' per the original text in Section 8.4 of
by setting the connection address to 0.0.0.0. Its usage for putting 3264.-->
a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks <blockquote>RFC 2543 [10] specified that placing a user on hold was acco
with connection oriented media. However, it can be useful in an mplished
initial offer when the offerer knows it wants to use a particular set by setting the connection address to 0.0.0.0. Its usage for putting
of media streams and formats, but doesn't know the addresses and a call on hold is no longer recommended, since it doesn't allow for
ports at the time of the offer. Of course, when used, the port RTCP to be used with held streams, doesn't work with IPv6, and breaks
number MUST NOT be zero, which would specify that the stream has been with connection oriented media. However, it can be useful in an
disabled. An agent MUST be capable of receiving SDP with a initial offer when the offerer knows it wants to use a particular set
connection address of 0.0.0.0, in which case it means that neither of media streams and formats, but doesn't know the addresses and
RTP nor RTCP is to be sent to the peer. ports at the time of the offer. Of course, when used, the port
</t> number <bcp14>MUST NOT</bcp14> be zero, which would specify that the stream h
</section> as been
<section anchor="sec-3264-new-8_4" title="New text replacing section 8.4 (6t disabled. An agent <bcp14>MUST</bcp14> be capable of receiving SDP with a
h paragraph) of RFC 3264" toc="default"> connection address of 0.0.0.0, in which case it means that neither
<t> RTP nor RTCP should be sent to the peer.
RFC 2543 [10] specified that placing a user on hold was accomplished </blockquote>
</section>
<section anchor="sec-3264-new-8_4" toc="default" numbered="true">
<name>New Text Replacing RFC 3264, Section 8.4, 6th Paragraph</name>
<!-- [rfced] RFC 2543 has been obsoleted by RFC 3261. Since RFC 2543
is essential to the text, instead of replacing it, we
suggest mentioning RFC 3261 (e.g., "Note that RFC 2543 has been
obsoleted by RFC 3261"); see Section 4.8.6 in the RFC Style Guide
(RFC 7322) for reference. Please let us know if this is agreeable
or if you prefer otherwise.
Also, RFC 2543 does not have a corresponding entry in the
references section. We added the entry under "Informative
References". If this is not correct and you would like to add it
under "Normative References", please let us know.
Original:
RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0.
Perhaps:
[RFC2543] specifies that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0 (note that RFC 2543 has been
obsoleted by RFC 3261).
Current:
19.2. Informative References
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
DOI 10.17487/RFC2543, March 1999,
<https://www.rfc-editor.org/info/rfc2543>.
-->
<t>
RFC 2543 <xref target="RFC2543"/> specifies that placing a user on hold
was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media. However, it can be useful in an with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, if it would specify that the stream has been number <bcp14>MUST NOT</bcp14> be zero, if it would specify that the str eam has been
disabled. However, an extension mechanism might specify different disabled. However, an extension mechanism might specify different
semantics of the zero port number usage. An agent MUST be capable semantics of the zero port number usage. An agent <bcp14>MUST</bcp14> be capable
of receiving SDP with a connection address of 0.0.0.0, in which case it of receiving SDP with a connection address of 0.0.0.0, in which case it
means that neither RTP nor RTCP is to be sent to the peer. means that neither RTP nor RTCP is to be sent to the peer.
</t> </t>
</section>
</section> </section>
</section> <section anchor="sec-5888" toc="default" numbered="true">
<name>Update to RFC 5888</name>
<section anchor="sec-5888" title="Update to RFC 5888" toc="default">
<t>
This section updates RFC 5888 <xref format="default" pageno="false" targ
et="RFC5888"/>),
in order to allow extensions to allow an SDP 'group' attribute containin
g
an identification-tag that identifies a "m=" section with the port set t
o zero
Section 9.2 (Group Value in Answers) of RFC 5888 is updated.
</t>
<section anchor="sec-5888-old-9_2" title="Original text of section 9.2 (3rd
paragraph) of RFC 5888" toc="default">
<t> <t>
SIP entities refuse media streams by setting the port to zero in the cor This section updates RFC 5888 <xref format="default" target="RFC5888"/>,
responding in order for extensions to allow an SDP 'group' attribute containing
"m" line. "a=group" lines MUST NOT contain identification-tags that corr an identification-tag that identifies an "m=" section with the port set
espond to to zero.
"m" lines with the port set to zero. "Group Value in Answers" (<xref target="RFC5888" sectionFormat="of" sec
tion="9.2"/>)
is updated.
</t> </t>
</section> <section anchor="sec-5888-old-9_2" toc="default" numbered="true">
<section anchor="sec-5888-new-9_2" title="New text replacing section 9.2 (3r <name>Original Text from RFC 5888, Section 9.2, 3rd Paragraph</name>
d paragraph) of RFC 5888" toc="default">
<t> <blockquote>SIP entities refuse media streams by setting the port to zer
o in the corresponding
"m" line. "a=group" lines <bcp14>MUST NOT</bcp14> contain identification
-tags that correspond to
"m" lines with the port set to zero.</blockquote>
</section>
<section anchor="sec-5888-new-9_2" toc="default" numbered="true">
<name>New Text Replacing RFC 5888, Section 9.2, 3rd Paragraph</name>
<t>
SIP entities refuse media streams by setting the port to zero in the cor responding SIP entities refuse media streams by setting the port to zero in the cor responding
"m" line. "a=group" lines MUST NOT contain identification-tags that corr espond to "m" line. "a=group" lines <bcp14>MUST NOT</bcp14> contain identification -tags that correspond to
"m" lines with the port set to zero, but an extension mechanism might sp ecify different "m" lines with the port set to zero, but an extension mechanism might sp ecify different
semantics for including identification-tags that correspond to such "m=" lines. semantics for including identification-tags that correspond to such "m=" lines.
</t> </t>
</section>
</section> </section>
</section> <section anchor="sec-receiver-id" toc="default" numbered="true">
<name>RTP/RTCP Extensions for identification-tag Transport</name>
<section title="RTP/RTCP extensions for identification-tag transport" anchor
="sec-receiver-id" toc="default">
<t> <t>
SDP Offerers and Answerers <xref format="default" pageno="false" target= "RFC3264"/> SDP Offerers and Answerers <xref format="default" target="RFC3264"/>
can associate identification-tags with "m=" sections within SDP Offers can associate identification-tags with "m=" sections within SDP Offers
and Answers, using the procedures in <xref format="default" pageno="fals and Answers, using the procedures in <xref format="default" target="RFC5
e" 888"/>. Each identification-tag uniquely represents an "m=" section.
target="RFC5888"/>. Each identification-tag uniquely represents an "m="
section.
</t> </t>
<t> <t>
This section defines a new RTCP SDES item <xref format="default" pageno= This section defines a new RTCP SDES item <xref format="default" target=
"false" "RFC3550"/>, 'MID', which is used to carry identification-tags within RTCP
target="RFC3550"/>, 'MID', which is used to carry identification-tags wi
thin RTCP
SDES packets. This section also defines a new RTP SDES header extension SDES packets. This section also defines a new RTP SDES header extension
<xref format="default" pageno="false" target="RFC7941"/>, which <xref format="default" target="RFC7941"/>, which
is used to carry the 'MID' RTCP SDES item in RTP packets. is used to carry the 'MID' RTCP SDES item in RTP packets.
</t> </t>
<t> <t>
The SDES item and RTP SDES header extension make it possible for a recei ver to associate The SDES item and RTP SDES header extension make it possible for a recei ver to associate
each RTP stream with a specific "m=" section, with which the receiver ha s each RTP stream with a specific "m=" section, with which the receiver ha s
associated an identification-tag, even if those "m=" sections are part o f the same RTP session. associated an identification-tag, even if those "m=" sections are part o f the same RTP session.
The RTP SDES header extension also ensures that the media recipient gets the identification-tag The RTP SDES header extension also ensures that the media recipient gets the identification-tag
upon receipt of the first decodable media and is able to associate the m edia with the upon receipt of the first decodable media and is able to associate the m edia with the
correct application. correct application.
</t> </t>
<t> <t>
A media recipient informs the media sender about the identification-tag A media recipient informs the media sender about the identification-tag
associated with an "m=" section through the use of an 'mid' attribute associated with an "m=" section through the use of an 'mid' attribute
<xref format="default" pageno="false" target="RFC5888"/>. The media send er then <xref format="default" target="RFC5888"/>. The media sender then
inserts the identification-tag in RTCP and RTP packets sent to the media recipient. inserts the identification-tag in RTCP and RTP packets sent to the media recipient.
</t> </t>
<t> <t>
NOTE: This text above defines how identification-tags are carried in SDP Offers NOTE: The text above defines how identification-tags are carried in SDP Offers
and Answers. The usage of other signaling protocols for carrying identif ication-tags and Answers. The usage of other signaling protocols for carrying identif ication-tags
is not prevented, but the usage of such protocols is outside the scope o f this document. is not prevented, but the usage of such protocols is outside the scope o f this document.
</t> </t>
<t> <t>
<xref format="default" pageno="false" target="RFC3550"/> defines general <xref format="default" target="RFC3550"/> defines general procedures
procedures regarding the RTCP transmission interval. The RTCP MID SDES item <bcp14>
regarding the RTCP transmission interval. The RTCP MID SDES item SHOULD SHOULD</bcp14> be sent in
be sent in the first few RTCP packets after joining the session and <bcp14>SHOULD</
the first few RTCP packets sent after joining the session, and SHOULD be bcp14> be sent regularly
sent regularly
thereafter. The exact number of RTCP packets in which this SDES item is sent is thereafter. The exact number of RTCP packets in which this SDES item is sent is
intentionally not specified here, as it will depend on the expected pack et loss intentionally not specified here, as it will depend on the expected pack et-loss
rate, the RTCP reporting interval, and the allowable overhead. rate, the RTCP reporting interval, and the allowable overhead.
</t> </t>
<t> <t>
The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD be included The RTP SDES header extension for carrying the 'MID' RTCP SDES <bcp14>SH OULD</bcp14> be included
in some RTP packets at the start of the session and whenever the SSRC ch anges. It might in some RTP packets at the start of the session and whenever the SSRC ch anges. It might
also be useful to include the header extension in RTP packets that compr ise access points in the media also be useful to include the header extension in RTP packets that compr ise access points in the media
(e.g., with video I-frames). The exact number of RTP packets in which th is header (e.g., with video I-frames). The exact number of RTP packets in which th is header
extension is sent is intentionally not specified here, as it will depend on expected extension is sent is intentionally not specified here, as it will depend on expected
packet loss rate and loss patterns, the overhead the application can tol erate, and packet-loss rate and loss patterns, the overhead the application can tol erate, and
the importance of immediate receipt of the identification-tag. the importance of immediate receipt of the identification-tag.
</t> </t>
<t> <t>
For robustness, endpoints need to be prepared for situations where the For robustness, endpoints need to be prepared for situations where the
reception of the identification-tag is delayed, and SHOULD NOT terminate sessions reception of the identification-tag is delayed and <bcp14>SHOULD NOT</bc p14> terminate sessions
in such cases, as the identification-tag is likely to arrive soon. in such cases, as the identification-tag is likely to arrive soon.
</t> </t>
<section title="RTCP MID SDES Item" anchor="sec-receiver-id-sdes-item" toc=" <section anchor="sec-receiver-id-sdes-item" toc="default" numbered="true">
default"> <name>RTCP MID SDES Item</name>
<figure> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MID=TBD | length | identification-tag ... | MID=15 | length | identification-tag ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
]]></artwork>
</figure>
<t> <t>
The identification-tag payload is UTF-8 encoded <xref format="default" The identification-tag payload is UTF-8 encoded <xref format="default"
pageno="false" target="RFC3629"/>, as in SDP. target="RFC3629"/>, as in SDP.
</t> </t>
<t> <t>
The identification-tag is not zero terminated. The identification-tag is not zero terminated.
</t> </t>
<t> </section>
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES <section anchor="sec-receiver-id-rtp-he" toc="default" numbered="true">
identifier value.] <name>RTP SDES Header Extension For MID</name>
</t>
</section>
<section title="RTP SDES Header Extension For MID" anchor="sec-receiver-id-r
tp-he" toc="default">
<t> <t>
The payload, containing the identification-tag, of the RTP SDES header extension element The payload, containing the identification-tag, of the RTP SDES header extension element
can be encoded using either the one-byte or two-byte header <xref form can be encoded using either the 1-byte or the 2-byte header <xref form
at="default" at="default" target="RFC7941"/>. The identification-tag payload is UTF-8
pageno="false" target="RFC7941"/>. The identification-tag payload is U
TF-8
encoded, as in SDP. encoded, as in SDP.
</t> </t>
<t> <t>
The identification-tag is not zero terminated. Note, that the set of h eader extensions The identification-tag is not zero terminated. Note that the set of he ader extensions
included in the packet needs to be padded to the next 32-bit boundary using zero included in the packet needs to be padded to the next 32-bit boundary using zero
bytes <xref format="default" pageno="false" target="RFC8285"/>. bytes <xref format="default" target="RFC8285"/>.
</t> </t>
<t> <t>
As the identification-tag is included in either an RTCP SDES item or a n RTP SDES header As the identification-tag is included in an RTCP SDES item, an RTP SDE S header
extension, or both, there needs to be some consideration about the pac ket expansion extension, or both, there needs to be some consideration about the pac ket expansion
caused by the identification-tag. To avoid Maximum Transmission Unit ( MTU) issues caused by the identification-tag. To avoid Maximum Transmission Unit ( MTU) issues
for the RTP packets, the header extension's size needs to be taken int o account when for the RTP packets, the header extension's size needs to be taken int o account when
encoding the media. encoding the media.
</t> </t>
<t> <t>
It is recommended that the identification-tag is kept short. Due to th It is recommended that the identification-tag be kept short. Due to th
e properties of e properties of
the RTP header extension mechanism, when using the one-byte header, a the RTP header extension mechanism, when using the 1-byte header, a ta
tag that is 1-3 bytes g that is 1-3 bytes
will result in a minimal number of 32-bit words used for the RTP SDES header extension, will result in a minimal number of 32-bit words used for the RTP SDES header extension,
in case no other header extensions are included at the same time. Note , do take into in case no other header extensions are included at the same time. Note , do take into
account that some single characters when UTF-8 encoded will result in multiple octets. account that some single characters when UTF-8 encoded will result in multiple octets.
The identification-tag MUST NOT contain any user information, and appl The identification-tag <bcp14>MUST NOT</bcp14> contain any user inform
ications SHALL avoid ation, and applications <bcp14>SHALL</bcp14> avoid
generating the identification-tag using a pattern that enables user- o generating the identification-tag using a pattern that enables user or
r application application
identification. identification.
</t> </t>
</section>
</section> </section>
</section> <section anchor="sec-receiver-id-iana" toc="default" numbered="true">
<section title="IANA Considerations" anchor="sec-receiver-id-iana" toc="defaul <name>IANA Considerations</name>
t"> <section anchor="sec-receiver-id-iana-sdes-item" toc="default" numbered="t
<section title="New SDES item" anchor="sec-receiver-id-iana-sdes-item" toc=" rue">
default"> <name>New SDES Item</name>
<t> <t>
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number This document adds the MID SDES item to the IANA "RTP SDES Item
of this document.] Types" registry as follows:
</t> </t>
<t> <ul empty="true"><li>
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES <dl newline="false" spacing="normal">
identifier value.] <dt>Value:</dt><dd>15</dd>
</t> <dt>Abbrev.:</dt><dd>MID</dd>
<t> <dt>Name:</dt><dd>Media Identification</dd>
This document adds the MID SDES item to the IANA "RTP SDES item <dt>Reference:</dt><dd>RFC 8843</dd>
types" registry as follows: </dl></li></ul>
</t> </section>
<figure> <section anchor="sec-receiver-id-iana-rtp-uri" toc="default" numbered="tru
<artwork align="left"><![CDATA[ e">
<name>New RTP SDES Header Extension URI</name>
Value: TBD <t>
Abbrev.: MID
Name: Media Identification
Reference: RFCXXXX
]]></artwork>
</figure>
</section>
<section title="New RTP SDES Header Extension URI" anchor="sec-receiver-id-i
ana-rtp-uri" toc="default">
<t>
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number
of this document.]
</t>
<t>
This document defines a new extension URI in the RTP SDES Compact Header Extensions This document defines a new extension URI in the RTP SDES Compact Header Extensions
sub-registry of the RTP Compact Header Extensions registry sub-registry, according sub-registry of the RTP Compact Header Extensions registry sub-registry, according
to the following data: to the following data:
</t> </t>
<figure> <ul empty="true"><li>
<artwork align="left"><![CDATA[ <dl newline="false" spacing="normal">
<dt>Extension URI:</dt><dd>urn:ietf:params:rtp-hdrext:sdes:mid</dd>
Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid <dt>Description:</dt><dd>Media identification</dd>
Description: Media identification <dt>Contact:</dt><dd>IESG (iesg@ietf.org)</dd>
Contact: IESG (iesg@ietf.org) <dt>Reference:</dt><dd>RFC 8843</dd>
Reference: RFCXXXX </dl></li></ul>
<t>
The SDES item does not reveal privacy information about the users. The SDES item does not reveal privacy information about the users.
It is simply used to associate RTP-based media with the correct SDP It is simply used to associate RTP-based media with the correct SDP
media description ("m=" section) in the SDP used to negotiate the media description ("m=" section) in the SDP used to negotiate the
media. media.</t>
The purpose of the extension is for the offerer to be able to <t> The purpose of the extension is for the offerer to be able to
associate received multiplexed RTP-based media before the offerer associate received multiplexed RTP-based media before the offerer
receives the associated SDP answer. receives the associated SDP answer.</t>
</section>
]]></artwork> <section anchor="sec-receiver-id-iana-sdp-attribute" toc="default" numbere
</figure> d="true">
</section> <name>New SDP Attribute</name>
<section title="New SDP Attribute" anchor="sec-receiver-id-iana-sdp-attribut <t>
e" toc="default">
<t>
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number
of this document.]
</t>
<t>
This document defines a new SDP media-level attribute, This document defines a new SDP media-level attribute,
'bundle-only', according to the following data: 'bundle-only', according to the following data:
</t> </t>
<figure> <ul empty="true"><li>
<artwork align="left"><![CDATA[ <dl newline="false" spacing="normal">
<dt>Attribute name:</dt><dd>bundle-only</dd>
Attribute name: bundle-only <dt>Type of attribute:</dt><dd>media</dd>
Type of attribute: media <dt>Subject to charset:</dt><dd>No</dd>
Subject to charset: No <dt>Purpose:</dt><dd>Request a media description to be accepted
Purpose: Request a media description to be accepted
in the answer only if kept within a BUNDLE in the answer only if kept within a BUNDLE
group by the answerer. group by the answerer.</dd>
Appropriate values: N/A <dt>Appropriate values:</dt><dd>N/A</dd>
Contact name: IESG <dt>Contact name:</dt><dd>IESG</dd>
Contact e-mail: iesg@ietf.org <dt>Contact e-mail:</dt><dd>iesg@ietf.org</dd>
Reference: RFCXXXX <dt>Reference:</dt><dd>RFC 8843</dd>
Mux category: NORMAL <dt>Mux category:</dt><dd>NORMAL</dd>
</dl></li></ul>
]]></artwork>
</figure>
</section>
<section title="New SDP Group Semantics" anchor="sec-receiver-id-iana-sdp-gr </section>
oup-semantics" toc="default"> <section anchor="sec-receiver-id-iana-sdp-group-semantics" toc="default" n
<t> umbered="true">
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number <name>New SDP Group Semantics</name>
of this document.] <t>
</t>
<t>
This document registers the following semantics with IANA in the This document registers the following semantics with IANA in the
"Semantics for the "group" SDP Attribute" subregistry (under the "Semantics for the "group" SDP Attribute" subregistry (under the
"Session Description Protocol (SDP) Parameters" registry: "Session Description Protocol (SDP) Parameters" registry:
</t> </t>
<figure>
<artwork align="left"><![CDATA[
Semantics Token Reference
------------------------------------- ------ ---------
Media bundling BUNDLE [RFCXXXX]
Mux category: NORMAL
]]></artwork> <table anchor="Table_1" align="left">
</figure> <thead>
<tr>
<th align="left">Semantics</th>
<th align="left">Token</th>
<th align="left">Mux Category</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Media bundling</td>
<td align="left">BUNDLE</td>
<td align="left">NORMAL</td>
<td align="left">RFC 8843</td>
</tr>
</tbody>
</table>
</section>
</section> </section>
</section> <section anchor="sec-security" toc="default" numbered="true">
<name>Security Considerations</name>
<section anchor="sec-security" title="Security Considerations" toc="default" <t>The security considerations defined in <xref format="default" target="R
> FC3264"/> and <xref format="default" target="RFC5888"/> apply to the BUNDLE exte
<t>The security considerations defined in <xref format="default" nsion. BUNDLE
pageno="false" target="RFC3264"/> and <xref format="default"
pageno="false" target="RFC5888"/> apply to the BUNDLE extension. Bundle
does not change which information, e.g., RTP streams, flows over does not change which information, e.g., RTP streams, flows over
the network, with the exception of the usage of the MID SDES item as the network, with the exception of the usage of the MID SDES item as
discussed below. Primarily it changes which addresses and ports, and discussed below.
thus in which (RTP) sessions the information is flowing. This Primarily, it changes which addresses and ports, and
thus in which (RTP) sessions, the information flows to. This
affects the security contexts being used and can cause previously affects the security contexts being used and can cause previously
separated information flows to share the same security context. This has v ery separated information flows to share the same security context. This has v ery
little impact on the performance of the security mechanism of the RTP little impact on the performance of the security mechanism of the RTP
sessions. In cases where one would have applied different security sessions. In cases where one would have applied different security
policies on the different RTP streams being bundled, or where the policies on the different RTP streams being bundled, or where the
parties having access to the security contexts would have differed parties having access to the security contexts would have differed
between the RTP streams, additional analysis of the implications are between the RTP streams, additional analysis of the implications are
needed before selecting to apply BUNDLE.</t> needed before selecting to apply BUNDLE.</t>
<t>The identification-tag, independent of transport, RTCP SDES packet or <t>The identification-tag, independent of transport, RTCP SDES packet, or
RTP header extension, can expose the value to parties beyond the RTP header extension, can expose the value to parties beyond the
signaling chain. Therefore, the identification-tag values MUST be signaling chain. Therefore, the identification-tag values <bcp14>MUST</bcp 14> be
generated in a fashion that does not leak user information, e.g., generated in a fashion that does not leak user information, e.g.,
randomly or using a per-bundle group counter, and SHOULD be 3 bytes or randomly or using a per-bundle group counter, and <bcp14>SHOULD</bcp14> be
less, to allow them to efficiently fit into the MID RTP header 3 bytes or
less to allow them to efficiently fit into the MID RTP header
extension. Note that if implementations use different methods for extension. Note that if implementations use different methods for
generating identification-tags this could enable fingerprinting of the generating identification-tags, this could enable fingerprinting of the
implementation making it vulnerable to targeted attacks. The implementation making it vulnerable to targeted attacks. The
identification-tag is exposed on the RTP stream level when included in identification-tag is exposed on the RTP stream level when included in
the RTP header extensions, however what it reveals of the RTP media the RTP header extensions; however, what it reveals of the RTP media
stream structure of the endpoint and application was already possible to stream structure of the endpoint and application was already possible to
deduce from the RTP streams without the MID SDES header extensions. As deduce from the RTP streams without the MID SDES header extensions. As
the identification-tag is also used to route the media stream to the the identification-tag is also used to route the media stream to the
right application functionality it is important that the value right application functionality, it is important that the value
received is the one intended by the sender, thus integrity and the received is the one intended by the sender; thus, integrity and the
authenticity of the source are important to prevent denial of service on authenticity of the source are important to prevent denial of service on
the application. Existing SRTP configurations and other security the application. Existing SRTP configurations and other security
mechanisms protecting the whole RTP/RTCP packets will provide the mechanisms protecting the whole RTP/RTCP packets will provide the
necessary protection.</t> necessary protection.</t>
<t>When the BUNDLE extension is used, the set of configurations of the <t>When the BUNDLE extension is used, the set of configurations of the
security mechanism used in all the bundled media descriptions will need to security mechanism used in all the bundled media descriptions will need to
be compatible so that they can be used simultaneously, at least be compatible so that they can be used simultaneously, at least
per direction or endpoint. When using SRTP this will be the case, at le per direction or endpoint. When using SRTP, this will be the case, at l
ast east
for the IETF defined key-management solutions due to their SDP attribut for the IETF-defined key-management solutions due to their SDP attribut
es es
(a=crypto, a=fingerprint, a=mikey) and their classification in <xref ("a=crypto", "a=fingerprint", "a=mikey") and their classification in <x
target="I-D.ietf-mmusic-sdp-mux-attributes"/>.</t> ref
target="RFC8859" format="default"/>.</t>
<t>The security considerations of "RTP Header <t>The security considerations of "RTP Header
Extension for the RTP Control Protocol (RTCP) Source Description Items" Extension for the RTP Control Protocol (RTCP) Source Description Items"
<xref target="RFC7941"/> requires that when RTCP is confidentiality pro tected, then any SDES <xref target="RFC7941" format="default"/> require that when RTCP is con fidentiality protected, any SDES
RTP header extension carrying an SDES item, such as the MID RTP header RTP header extension carrying an SDES item, such as the MID RTP header
extension, is also protected using commensurate strength algorithms. extension, is also protected using commensurate strength algorithms.
However, assuming the above requirements and recommendations are However, assuming the above requirements and recommendations are
followed, there are no known significant security risks with leaving the followed, there are no known significant security risks with leaving the
MID RTP header extension without confidentiality protection. MID RTP header extension without confidentiality protection.
Therefore, this specification updates RFC 7941 by adding the exception tha t this requirement Therefore, this specification updates RFC 7941 by adding the exception tha t this requirement
MAY be ignored for the MID RTP header extension. Security mechanisms for R <bcp14>MAY</bcp14> be ignored for the MID RTP header extension. Security m
TP/RTCP are echanisms for RTP/RTCP are
discussed in Options for Securing RTP Sessions <xref target="RFC7201"/>, discussed in "Options for Securing RTP Sessions" <xref target="RFC7201" fo
for example SRTP <xref target="RFC3711"/> can provide the necessary securi rmat="default"/>,
ty for example, SRTP <xref target="RFC3711" format="default"/> can provide th
e necessary security
functions of ensuring the integrity and source authenticity. functions of ensuring the integrity and source authenticity.
</t> </t>
</section> </section>
<section anchor="sec-example-alt1" toc="default" numbered="true">
<section title="Examples" anchor="sec-example-alt1" toc="default"> <name>Examples</name>
<section title="Example: Tagged m= Section Selections" anchor="sec-example-a <section anchor="sec-example-add" toc="default" numbered="true">
dd" <name>Example: Tagged "m=" Section Selections</name>
toc="default"> <t>
<t>
The example below shows: The example below shows:
<list style="symbols"> </t>
<t>An initial BUNDLE offer, in which the offerer wants to negotiate a <ul spacing="normal">
BUNDLE group, and indicates the audio m= section as the suggested offerer tagged
"m=" section.</t>
<t>An initial BUNDLE answer, in which the answerer accepts the creatio
n of the BUNDLE group, selects the audio m= section in the offer as the offerer
tagged "m=" section,
selects the audio "m=" section in the answer as the answerer tagged "m
=" section and assigns the answerer BUNDLE address:port to that "m=" section.</t
>
</list>
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer (1) <li>An initial BUNDLE offer, in which the offerer wants to
negotiate a BUNDLE group and indicates the audio "m="
section as the suggested offerer-tagged "m=" section.</li>
<li>An initial BUNDLE answer, in which the answerer accepts
the creation of the BUNDLE group, selects the audio "m="
section in the offer as the offerer-tagged "m=" section,
selects the audio "m=" section in the answer as the
answerer-tagged "m=" section, and assigns the answerer BUNDLE
address:port to that "m=" section.</li>
</ul>
<t keepWithNext="true">SDP Offer (1)</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at line 2191 skipping to change at line 2214
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux a=rtcp-mux
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
]]></sourcecode>
SDP Answer (2) <t keepWithNext="true">SDP Answer (2)</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
]]></sourcecode>
]]></artwork> </section>
</figure> <section anchor="sec-example-bunrej" toc="default" numbered="true">
</section> <name>Example: BUNDLE Group Rejected</name>
<t>
<section title="Example: BUNDLE Group Rejected" anchor="sec-example-bunrej"
toc="default">
<t>
The example below shows: The example below shows:
<list style="symbols"> </t>
<t>An initial BUNDLE offer, in which the offerer wants to negotiate a <ul spacing="normal">
BUNDLE group, and indicates the audio m= section as the suggested offerer tagged <li>An initial BUNDLE offer, in which the offerer wants to
"m=" section.</t> negotiate a BUNDLE group and indicates the audio "m=" section
<t>An initial BUNDLE answer, in which the answerer rejects the creatio as the suggested offerer-tagged "m=" section.</li>
n of the BUNDLE group, generates a normal answer and assigns a unique address:po
rt to each "m="
section in the answer.</t>
</list>
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer (1) <li>An initial BUNDLE answer, in which the answerer rejects
the creation of the BUNDLE group, generates a normal answer,
and assigns a unique address:port to each "m=" section in
the answer.</li>
</ul>
<t keepWithNext="true">SDP Offer (1)</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at line 2258 skipping to change at line 2282
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux a=rtcp-mux
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
]]></sourcecode>
SDP Answer (2) <t keepWithNext="true">SDP Answer (2)</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32 m=video 30000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=rtcp-mux a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
]]></sourcecode>
]]></artwork> </section>
</figure> <section anchor="sec-example-off-add" toc="default" numbered="true">
</section> <name>Example: Offerer Adds a Media Description to a BUNDLE Group</name>
<t>
<section title="Example: Offerer Adds a Media Description to a BUNDLE Group"
anchor="sec-example-off-add" toc="default">
<t>
The example below shows: The example below shows:
<list style="symbols"> </t>
<t>A subsequent offer, in which the offerer adds a new bundled "m=" se <ul spacing="normal">
ction (video), indicated by the "zen" <li>A subsequent offer, in which the offerer adds a new bundled "m=" s
identification-tag, to a previously negotiated BUNDLE group, indicates ection (video), indicated by the "zen"
the new "m=" section as the identification-tag, to a previously negotiated BUNDLE group; indicates
offerer tagged "m=" section and assigns the offerer BUNDLE address:por the new "m=" section as the
t to that "m=" section.</t> offerer-tagged "m=" section; and assigns the offerer BUNDLE address:po
<t>A subsequent answer, in which the answerer indicates the new video rt to that "m=" section.</li>
"m=" section in the answer as the answerer tagged "m=" section
and assigns the answerer BUNDLE address:port to that "m=" section.</t>
</list>
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer (1) <li>A subsequent answer, in which the answerer indicates the new video
"m=" section in the answer as the answerer-tagged "m=" section
and assigns the answerer BUNDLE address:port to that "m=" section.</li
>
</ul>
<t keepWithNext="true">SDP Offer (1)</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE zen foo bar a=group:BUNDLE zen foo bar
m=audio 0 RTP/AVP 0 8 97 m=audio 0 RTP/AVP 0 8 97
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at line 2328 skipping to change at line 2350
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 66 m=video 10000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
]]></sourcecode>
SDP Answer (2) <t keepWithNext="true">SDP Answer (2)</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE zen foo bar a=group:BUNDLE zen foo bar
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at line 2358 skipping to change at line 2382
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
]]></sourcecode>
]]></artwork> </section>
</figure> <section anchor="sec-example-off-mov" toc="default" numbered="true">
</section> <name>Example: Offerer Moves a Media Description Out of a BUNDLE Group</
name>
<section title="Example: Offerer Moves a Media Description Out of a BUNDLE G <t>
roup" anchor="sec-example-off-mov" toc="default">
<t>
The example below shows: The example below shows:
<list style="symbols"> </t>
<t>A subsequent offer, in which the offerer removes a "m=" section (vi <ul spacing="normal">
deo), indicated by the "zen" <li>A subsequent offer, in which the offerer removes an "m=" section (
identification-tag, from a previously negotiated BUNDLE group, indicat video), indicated by the "zen"
es one of the bundled "m=" sections (audio) identification-tag, from a previously negotiated BUNDLE group; indicat
remaining in the BUNDLE group as the offerer tagged "m=" section and a es one of the bundled "m=" sections (audio)
ssigns the offerer BUNDLE address:port to that "m=" section.</t> remaining in the BUNDLE group as the offerer-tagged "m=" section; and
<t>A subsequent answer, in which the answerer removes the "m=" section assigns the offerer BUNDLE address:port to that "m=" section.</li>
from the BUNDLE group, indicates the audio "m=" section
in the answer as the answerer tagged "m=" section and assigns the answ
erer BUNDLE address:port to that "m=" section.</t>
</list>
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer (1) <li>A subsequent answer, in which the answerer removes the "m=" sectio
n from the BUNDLE group, indicates the audio "m=" section
in the answer as the answerer-tagged "m=" section, and assigns the ans
werer BUNDLE address:port to that "m=" section.</li>
</ul>
<t keepWithNext="true">SDP Offer (1)</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at line 2409 skipping to change at line 2430
a=bundle-only a=bundle-only
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 50000 RTP/AVP 66 m=video 50000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
]]></sourcecode>
SDP Answer (2) <t keepWithNext="true">SDP Answer (2)</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at line 2438 skipping to change at line 2461
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 60000 RTP/AVP 66 m=video 60000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
]]></sourcecode>
]]></artwork> </section>
</figure> <section anchor="sec-example-off-dis" toc="default" numbered="true">
</section> <name>Example: Offerer Disables a Media Description within a BUNDLE Grou
p</name>
<section title="Example: Offerer Disables a Media Description Within a B <t>
UNDLE Group" anchor="sec-example-off-dis" toc="default">
<t>
The example below shows: The example below shows:
<list style="symbols"> </t>
<t>A subsequent offer, in which the offerer disables (by assigning a z <ul spacing="normal">
ero port value) a "m=" section (video), indicated by the "zen" <li>A subsequent offer, in which the offerer disables (by assigning a
identification-tag, from a previously negotiated BUNDLE group, indicat zero port value) an "m=" section (video), indicated by the "zen"
es one of the bundled "m=" sections (audio) identification-tag, from a previously negotiated BUNDLE group; indicat
remaining active in the BUNDLE group as the offerer tagged "m=" sectio es one of the bundled "m=" sections (audio)
n and assigns the offerer BUNDLE address:port to that "m=" section.</t> remaining active in the BUNDLE group as the offerer-tagged "m=" sectio
<t>A subsequent answer, in which the answerer disables the "m=" sectio n; and assigns the offerer BUNDLE address:port to that "m=" section.</li>
n, indicates the audio "m=" section
in the answer as the answerer tagged "m=" section and assigns the answ
erer BUNDLE address:port to that "m=" section.</t>
</list>
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer (1) <li>A subsequent answer, in which the answerer disables the "m=" secti
on, indicates the audio "m=" section
in the answer as the answerer-tagged "m=" section, and assigns the ans
werer BUNDLE address:port to that "m=" section.</li>
</ul>
<t keepWithNext="true">SDP Offer (1)</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at line 2488 skipping to change at line 2507
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
]]></sourcecode>
SDP Answer (2) <t keepWithNext="true">SDP Answer (2)</t>
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at line 2516 skipping to change at line 2537
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
]]></sourcecode>
]]></artwork> </section>
</figure>
</section> </section>
</section>
<section anchor="sec-acks" title="Acknowledgements" toc="default"> </middle>
<t> <back>
The usage of the SDP grouping extension for negotiating bundled media is
based on similar alternatives proposed by Harald Alvestrand and Cullen
Jennings. The BUNDLE extension described in this document is based on
the different alternative proposals, and text (e.g., SDP examples)
have been borrowed (and, in some cases, modified) from those alternative
proposals.
</t>
<t>
The SDP examples are also modified versions from the ones in the Alvestran
d
proposal.
</t>
<t>
Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Stach,
Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, Suhas Nandakumar
, Nils
Ohlmeier, Jens Guballa, Raju Makaraju, Justin Uberti, Taylor Brandstetter,
Byron
Campen and Eric Rescorla for reading the text, and providing useful feedba
ck.
</t>
<t>
Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti,
and Magnus Westerlund for providing the text for the section on
RTP/RTCP stream association.
</t>
<t>
Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for providi
ng
help and text on the RTP/RTCP procedures.
</t>
<t>
Thanks to Charlie Kaufman for performing the Sec-Dir review.
</t>
<t>
Thanks to Linda Dunbar for performing the Gen-ART review.
</t>
<t>
Thanks to Spotify for providing music for the countless hours of
document editing.
</t>
</section>
<section title="Change Log"> <displayreference target="I-D.ietf-avtext-lrr" to="LLR-RTCP"/>
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-51
<list style="symbols">
<t>Changes based on IESG reviews.</t>
<t>- Clarification of 'initial offer' terminology.</t>
<t>- Merging of tagged m- section selection sections.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50
<list style="symbols">
<t>Changes based on IESG reviews.</t>
<t>- Adding of tagged m- section concept.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49
<list style="symbols">
<t>Changes based on IESG reviews.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-48
<list style="symbols">
<t>Changes based on Sec-Dir review by Charlie Kaufman.</t>
<t>- s/unique address/unique address:port</t>
<t>Changes based on Gen-ART review by Linda Dunbar.</t>
<t>Mux category for group:BUNDLE attribute added.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47
<list style="symbols">
<t>Changes based on AD review by Ben Campbell.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46
<list style="symbols">
<t>Pre-RFC5378 disclaimer removed put back.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45
<list style="symbols">
<t>Mux category for SDP 'group:BUNDLE' attribute added.</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/54</t>
<t>Pre-RFC5378 disclaimer removed.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-44
<list style="symbols">
<t>Minor editorial nits based on pull request by Colin P.</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/53</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-43
<list style="symbols">
<t>Changes based on WG chairs review.</t>
<t>Text added in order to close GitHub issues by Taylor B.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-42
<list style="symbols">
<t>Changes based on final WG review.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41
<list style="symbols">
<t>Update to section 6 o RFC 3264:</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/47</t>
<t>Editorial clarification on BUNDLE address selection:</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/46</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40
<list style="symbols">
<t>Editorial changes and technical restrictions in order to make the
specification more understandable:</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/45</t>
<t>- BUNDLE address is only assigned to m- section indicated by BUNDLE-t
ag.</t>
<t>- bundle-only attribute also used in answers and subsequent offers.</
t>
<t>- Answerer cannot reject, or remove, the bundled m- section that cont
ains the
BUNDLE address.</t>
<t>- ICE Offer/Answer sections removed, due to duplicated information.</
t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39
<list style="symbols">
<t>Editorial terminology changes.</t>
<t>RFC 5285 reference replaced by reference to RFC 8285.</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/44</t>
<t>- Clarify that an m- section can not be moved between BUNDLE groups
without first moving the m- section out of a BUNDLE group.</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/41</t>
<t>- Addition of BUNDLE transport concept.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38
<list style="symbols">
<t>Changes to RTP streaming mapping section based on text from Colin Per
kins.</t>
<t>The following GitHub pull requests were merged:</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/34</t>
<t>- Proposed updates to RTP processing</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/35</t>
<t>- fixed reference to receiver-id section</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37
<list style="symbols">
<t>The following GitHub pull request was merged:</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/33</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36
<list style="symbols">
<t>The following GitHub pull requests were merged:</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/32</t>
<t>- extmap handling in BUNDLE.</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/31</t>
<t>- Additional Acknowledgement text added.</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/30</t>
<t>- MID SDES item security procedures updated</t>
<t>https://github.com/cdh4u/draft-sdp-bundle/pull/29</t>
<t>- Appendix B of JSEP moved into BUNDLE.</t>
<t>- Associating RTP/RTCP packets with SDP m- lines.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35
<list style="symbols">
<t>Editorial changes on RTP streaming mapping section based on comments
from Colin Perkins.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34
<list style="symbols">
<t>RTP streams, instead of RTP packets, are associated with m- lines.</t
>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33
<list style="symbols">
<t>Editorial changes based on comments from Eric Rescorla and Cullen Jen
nings:</t>
<t>- Changes regarding usage of RTP/RTCP multiplexing attributes.</t>
<t>- Additional text regarding associating RTP/RTCP packets with SDP m-
lines.</t>
<t>- Reference correction.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32
<list style="symbols">
<t>Editorial changes based on comments from Eric Rescorla and Cullen Jen
nings:</t>
<t>- Justification for mechanism added to Introduction.</t>
<t>- Clarify that the order of m- lines in the group:BUNDLE
attribute does not have to be the same as the order in which
the m- lines are listed in the SDP.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31
<list style="symbols">
<t>Editorial changes based on GitHub Pull requests by Martin Thomson:</t
>
<t>- https://github.com/cdh4u/draft-sdp-bundle/pull/2</t>
<t>- https://github.com/cdh4u/draft-sdp-bundle/pull/1</t>
<t>Editorial change based on comment from Diederick Huijbers (9th July 2
016).</t>
<t>Changes based on comments from Flemming Andreasen (21st June 2016):</
t>
<t>- Mux category for SDP bundle-only attribute added.</t>
<t>- Mux category considerations editorial clarification.</t>
<t>- Editorial changes.</t>
<t>RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext.</t>
<t>Note whether Design Considerations appendix is to be kept removed:</t
>
<t>- Appendix is kept within document.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30
<list style="symbols">
<t>Indicating in the Abstract and Introduction that
the document updates RFC 3264.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29
<list style="symbols">
<t>Change based on WGLC comment from Colin Perkins.</t>
<t>- Clarify that SSRC can be reused by another source
after a delay of 5 RTCP reporting intervals.</t>
<t>Change based on WGLC comment from Alissa Cooper.</t>
<t>- IANA registry name fix.</t>
<t>- Additional IANA registration information added.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28
<list style="symbols">
<t>- Alignment with exclusive mux procedures.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27
<list style="symbols">
<t>- Yet another terminology change.</t>
<t>- Mux category considerations added.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26
<list style="symbols">
<t>- ICE considerations modified: ICE-related SDP attributes only added
to the bundled m- line representing the selected BUNDLE address.</t
>
<t>- Reference to draft-ietf-mmusic-ice-sip-sdp added.</t>
<t>- Reference to RFC 5245 replaced with reference to draft-ietf-ice-rfc
5245bis.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25
<list style="symbols">
<t>- RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux conside
rations.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24
<list style="symbols">
<t>- Reference and procedures associated with exclusive RTP/RTCP mux add
ed</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23
<list style="symbols">
<t>- RTCP-MUX mandatory for bundled RTP m- lines</t>
<t>- Editorial fixes based on comments from Flemming Andreasen</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22
<list style="symbols">
<t>- Correction of Ari's family name</t>
<t>- Editorial fixes based on comments from Thomas Stach</t>
<t>- RTP/RTCP correction based on comment from Magnus Westerlund</t>
<t>-- http://www.ietf.org/mail-archive/web/mmusic/current/msg14861.html<
/t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21
<list style="symbols">
<t>- Correct based on comment from Paul Kyzivat</t>
<t>-- 'received packets' replaced with 'received data'</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20
<list style="symbols">
<t>- Clarification based on comment from James Guballa</t>
<t>- Clarification based on comment from Flemming Andreasen</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19
<list style="symbols">
<t>- DTLS Considerations section added.</t>
<t>- BUNDLE semantics added to the IANA Considerations</t>
<t>- Changes based on WGLC comments from Adam Roach</t>
<t>-- http://www.ietf.org/mail-archive/web/mmusic/current/msg14673.html<
/t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18
<list style="symbols">
<t>- Changes based on agreements at IETF#92</t>
<t>-- BAS Offer removed, based on agreement at IETF#92.</t>
<t>-- Procedures regarding usage of SDP "b=" line is replaced with a
reference to to draft-ietf-mmusic-sdp-mux-attributes.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17
<list style="symbols">
<t>- Editorial changes based on comments from Magnus Westerlund.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16
<list style="symbols">
<t>- Modification of RTP/RTCP multiplexing section, based
on comments from Magnus Westerlund.</t>
<t>- Reference updates.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15
<list style="symbols">
<t>- Editorial fix.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14
<list style="symbols">
<t>- Editorial changes.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13
<list style="symbols">
<t>Changes to allow a newly suggested offerer BUNDLE address
to be assigned to each bundled m- line.</t>
<t>Changes based on WGLC comments from Paul Kyzivat</t>
<t>- Editorial fixes</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12
<list style="symbols">
<t>Usage of SDP 'extmap' attribute added</t>
<t>SDP 'bundle-only' attribute scoped with "m=" lines with a zero port v
alue</t>
<t>Changes based on WGLC comments from Thomas Stach</t>
<t>- ICE candidates not assigned to bundle-only m- lines with a zero por
t value</t>
<t>- Editorial changes</t>
<t>Changes based on WGLC comments from Colin Perkins</t>
<t>- Editorial changes:</t>
<t>-- "RTP SDES item" -> "RTCP SDES item"</t>
<t>-- "RTP MID SDES item" -> "RTCP MID SDES item"</t>
<t>- Changes in section 10.1.1:</t>
<t>-- "SHOULD NOT" -> "MUST NOT"</t>
<t>-- Additional text added to the Note</t>
<t>- Change to section 13.2:</t>
<t>-- Clarify that mid value is not zero terminated</t>
<t>- Change to section 13.3:</t>
<t>-- Clarify that mid value is not zero terminated</t>
<t>-- Clarify padding</t>
<t>Changes based on WGLC comments from Paul Kyzivat</t>
<t>- Editorial changes:</t>
<t>Changes based on WGLC comments from Jonathan Lennox</t>
<t>- Editorial changes:</t>
<t>- Defintion of SDP bundle-only attribute alligned with
structure in 4566bis draft</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11
<list style="symbols">
<t>Editorial corrections based on comments from Harald Alvestrand.</t>
<t>Editorial corrections based on comments from Cullen Jennings.</t>
<t>Reference update (RFC 7160).</t>
<t>Clarification about RTCP packet sending when RTP/RTCP multiplexing
is not used (http://www.ietf.org/mail-archive/web/mmusic/current/msg1376
5.html).</t>
<t>Additional text added to the Security Considerations.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10
<list style="symbols">
<t>SDP bundle-only attribute added to IANA Considerations.</t>
<t>SDES item and RTP header extension added to Abstract and Introduction
.</t>
<t>Modification to text updating section 8.2 of RFC 3264.</t>
<t>Reference corrections.</t>
<t>Editorial corrections.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09
<list style="symbols">
<t>Terminology change: "bundle-only attribute assigned to m= line" to
"bundle-only attribute associated with m= line".</t>
<t>Editorial corrections.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08
<list style="symbols">
<t>Editorial corrections.</t>
<t>- "of"->"if" (8.3.2.5).</t>
<t>- "optional"->"OPTIONAL" (9.1).</t>
<t>- Syntax/ABNF for 'bundle-only' attribute added.</t>
<t>- SDP Offer/Answer sections merged.</t>
<t>- 'Request new offerer BUNDLE address' section added</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07
<list style="symbols">
<t>OPEN ISSUE regarding Receiver-ID closed.</t>
<t>- RTP MID SDES Item.</t>
<t>- RTP MID Header Extension.</t>
<t>OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers clo
sed.</t>
<t>- Indicating that, when rtcp-mux is used, the answerer MUST NOT inclu
de
an 'rtcp' attribute in the answer, based on the procedures in section 5.
1.3 of
RFC 5761.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06
<list style="symbols">
<t>Draft title changed.</t>
<t>Added "SDP" to section names containing "Offer" or "Answer".</t>
<t>Editorial fixes based on comments from Paul Kyzivat (http://www.ietf.
org/mail-archive/web/mmusic/current/msg13314.html).</t>
<t>Editorial fixed based on comments from Colin Perkins (http://www.ietf
.org/mail-archive/web/mmusic/current/msg13318.html).</t>
<t>- Removed text about extending BUNDLE to allow multiple RTP sessions
within a BUNDLE group.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05
<list style="symbols">
<t>Major re-structure of SDP Offer/Answer sections, to align with RFC 32
64 structure.</t>
<t>Additional definitions added.</t>
<t>- Shared address.</t>
<t>- Bundled "m=" line.</t>
<t>- Bundle-only "m=" line.</t>
<t>- Offerer suggested BUNDLE mid.</t>
<t>- Answerer selected BUNDLE mid.</t>
<t>Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address to m
ultiple "m=" lines until it has
received an SDP Answer indicating support of the BUNDLE extension.</t>
<t>Q8 Closed (IETF#88): An Offerer can, before it knows whether the Answ
erer supports the BUNDLE extension,
assign a zero port value to a 'bundle-only' "m=" line.</t>
<t>SDP 'bundle-only' attribute section added.</t>
<t>Connection data nettype/addrtype restrictions added.</t>
<t>RFC 3264 update section added.</t>
<t>Indicating that a specific payload type value can be used in multiple
"m=" lines, if the value
represents the same codec configuration in each "m=" line.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04
<list style="symbols">
<t>Updated Offerer procedures (http://www.ietf.org/mail-archive/web/mmus
ic/current/msg12293.html).</t>
<t>Updated Answerer procedures (http://www.ietf.org/mail-archive/web/mmu
sic/current/msg12333.html).</t>
<t>Usage of SDP 'bundle-only' attribute added.</t>
<t>Reference to Trickle ICE document added.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02
<list style="symbols">
<t>Mechanism modified, to be based on usage of SDP Offers
with both different and identical port number values, depending
on whether it is known if the remote endpoint supports the
extension.</t>
<t>Cullen Jennings added as co-author.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01
<list style="symbols">
<t>No changes. New version due to expiration.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00
<list style="symbols">
<t>No changes. New version due to expiration.</t>
</list>
</t>
<t>Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00
<list style="symbols">
<t>Draft name changed.</t>
<t>Harald Alvestrand added as co-author.</t>
<t>"Multiplex" terminology changed to "bundle".</t>
<t>Added text about single versus multiple RTP Sessions.</t>
<t>Added reference to RFC 3550.</t>
</list>
</t>
</section>
</middle>
<back> <references>
<references title="Normative References"> <name>References</name>
<?rfc include="reference.RFC.2119"?> <references>
<?rfc include="reference.RFC.3264"?> <name>Normative References</name>
<?rfc include="reference.RFC.3550"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.3605"?> ence.RFC.2119.xml"/>
<?rfc include="reference.RFC.3629"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include='reference.RFC.3711'?> ence.RFC.3264.xml"/>
<?rfc include="reference.RFC.4566"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.4961"?> ence.RFC.3550.xml"/>
<?rfc include="reference.RFC.5761"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.5764"?> ence.RFC.3605.xml"/>
<?rfc include="reference.RFC.5888"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.6347"?> ence.RFC.3629.xml"/>
<?rfc include="reference.RFC.7941"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.8174"?> ence.RFC.3711.xml"/>
<?rfc include="reference.RFC.8285"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.I-D.draft-ietf-ice-rfc5245bis-20"?> ence.RFC.4566.xml"/>
<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-mux-attributes-16"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.I-D.draft-ietf-mmusic-mux-exclusive-12"?> ence.RFC.4961.xml"/>
<?rfc include="reference.I-D.draft-ietf-mmusic-ice-sip-sdp-20"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.I-D.draft-ietf-mmusic-trickle-ice-sip-14"?> ence.RFC.5761.xml"/>
</references> <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.5888.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.7941.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.8285.xml"/>
<references title="Informative References"> <!--Note: reference.I-D.draft-ietf-ice-rfc5245bis-20 is now RFC 8445-->
<?rfc include="reference.RFC.3261"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.3611"?> ence.RFC.8445.xml"/>
<?rfc include="reference.RFC.5104"?>
<?rfc include="reference.RFC.4585"?>
<?rfc include="reference.RFC.5576"?>
<?rfc include="reference.RFC.7160"?>
<?rfc include="reference.RFC.7201"?>
<?rfc include="reference.RFC.7656"?>
<?rfc include="reference.RFC.7657"?>
<?rfc include="reference.I-D.draft-ietf-ice-trickle-21"?>
<?rfc include="reference.I-D.draft-ietf-avtext-lrr-07"?>
</references>
<section title="Design Considerations" toc="default"> <!--draft-ietf-mmusic-sdp-mux-attributes-17; part of C238; 8859 -->
<reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8
859">
<front>
<title>A Framework for SDP Attributes When Multiplexing</title>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
">
<organization/>
</author>
<date month="May" year="2020"/>
</front>
<seriesInfo name="DOI" value="10.17487/RFC8859"/>
<seriesInfo name="RFC" value="8859"/>
</reference>
<!--note: title updated per edits made (however, seems that 'the' should be inse
rted after 'Using')-->
<!--draft-ietf-mmusic-mux-exclusive-12; part of C238; RFC 8858-->
<reference anchor='RFC8858' target="https://www.rfc-editor.org/info/rfc8858">
<front>
<title>Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP</title>
<!-- OR
<title>Indicating Exclusive Support of RTP/RTCP Multiplexing Using Session
Description Protocol (SDP)</title>
-->
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<date month='May' year='2020' />
</front>
<seriesInfo name='RFC' value='8858' />
<seriesInfo name="DOI" value="10.17487/RFC8858"/>
</reference>
<!--draft-ietf-mmusic-ice-sip-sdp-39; part of C238; RFC 8839 -->
<reference anchor='RFC8839' target="https://www.rfc-editor.org/info/rfc8839">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures for Interactiv
e Connectivity Establishment (ICE)</title>
<author initials='M' surname='Petit-Huguenin' fullname='Marc Petit-Huguenin'>
<organization />
</author>
<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
<organization />
</author>
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<author initials='A' surname='Keränen' fullname='Ari Keränen'>
<organization />
</author>
<author initials='R' surname='Shpount' fullname='Roman Shpount'>
<organization />
</author>
<date month='May' year='2020' />
</front>
<seriesInfo name='RFC' value='8839' />
<seriesInfo name="DOI" value="10.17487/RFC8839"/>
</reference>
<!--draft-ietf-mmusic-trickle-ice-sip-18; part of C238 - 8840 -->
<reference anchor='RFC8840' target="https://www.rfc-editor.org/info/rfc8840">
<front>
<title>A Session Initiation Protocol (SIP) Usage for Incremental Provisioning
of Candidates for the Interactive Connectivity Establishment (Trickle
ICE)</title>
<author initials='E' surname='Ivov' fullname='Emil Ivov'>
<organization />
</author>
<author initials='T' surname='Stach' fullname='Thomas Stach'>
<organization />
</author>
<author initials='E' surname='Marocco' fullname='Enrico Marocco'>
<organization />
</author>
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<date month='May' year='2020' />
</front>
<seriesInfo name='RFC' value='8840' />
<seriesInfo name="DOI" value="10.17487/RFC8840"/>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2543.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3261.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3611.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5104.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.5576.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7160.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.7656.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7657.xml"/>
<!--draft-ietf-ice-trickle-21; part of C238; RFC-to-be 8838 -->
<reference anchor='RFC8838' target="https://www.rfc-editor.org/info/rfc8838">
<front>
<title>Trickle ICE: Incremental Provisioning of Candidates for the Interactive C
onnectivity Establishment (ICE) Protocol</title>
<author initials='E' surname='Ivov' fullname='Emil Ivov'>
<organization />
</author>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<author initials='J' surname='Uberti' fullname='Justin Uberti'>
<organization />
</author>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<date month="May" year="2020" />
</front>
<seriesInfo name="RFC" value="8838"/>
<seriesInfo name="DOI" value="10.17487/RFC8838"/>
</reference>
<!--draft-ietf-avtext-lrr-07; in MISSREF and part of C324-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.ietf-avtext-lrr.xml"/>
</references>
</references>
<section toc="default" numbered="true">
<name>Design Considerations</name>
<t> <t>
One of the main issues regarding the BUNDLE grouping extensions has been whether, One of the main issues regarding the BUNDLE grouping extensions has been whether,
in SDP Offers and SDP Answers, the same port value can be inserted in "m =" in SDP Offers and SDP Answers, the same port value can be inserted in "m ="
lines associated with a BUNDLE group, as the purpose of the extension is to negotiate lines associated with a BUNDLE group, as the purpose of the extension is to negotiate
the usage of a single transport for media specified by the "m=" sections . Issues the usage of a single transport for media specified by the "m=" sections . Issues
with both approaches, discussed in the Appendix have been raised. The ou with both approaches, discussed in the Appendix, have been raised. The o
tcome was to utcome was to
specify a mechanism which uses SDP Offers with both different and identi specify a mechanism that uses SDP Offers with both different and identic
cal port values. al port values.
</t> </t>
<t> <t>
Below are the primary issues that have been considered when defining the "BUNDLE" Below are the primary issues that have been considered when defining the "BUNDLE"
grouping extension: grouping extension:
<list style="symbols">
<t>1) Interoperability with existing UAs.</t>
<t>2) Interoperability with intermediary Back to Back User Agent (B2BU
A) and proxy entities.</t>
<t>3) Time to gather, and the number of, ICE candidates.</t>
<t>4) Different error scenarios, and when they occur.</t>
<t>5) SDP Offer/Answer impacts, including usage of port number value z
ero.</t>
</list>
</t> </t>
<ol spacing="normal" type="%d)">
<section title="UA Interoperability" toc="default"> <li>Interoperability with existing User Agents (UAs).</li>
<t> <li>Interoperability with intermediary Back-to-Back User Agent (B2BUA) a
nd proxy entities.</li>
<li>Time to gather, and the number of, ICE candidates.</li>
<li>Different error scenarios and when they occur.</li>
<li>SDP Offer/Answer impacts, including usage of port number value zero.
</li>
</ol>
<section toc="default" numbered="true">
<name>UA Interoperability</name>
<t>
Consider the following SDP Offer/Answer exchange, where Alice sends an S DP Offer to Bob: Consider the following SDP Offer/Answer exchange, where Alice sends an S DP Offer to Bob:
</t> </t>
<figure> <t keepWithNext="true">SDP Offer</t>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
m=audio 10000 RTP/AVP 97 m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 97 m=video 10002 RTP/AVP 97
a=rtpmap:97 H261/90000 a=rtpmap:97 H261/90000
]]></sourcecode>
<t keepWithNext="true">SDP Answer</t>
]]></artwork> <sourcecode type="sdp"><![CDATA[
</figure>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Answer
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
m=audio 20000 RTP/AVP 97 m=audio 20000 RTP/AVP 97
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 20002 RTP/AVP 97 m=video 20002 RTP/AVP 97
a=rtpmap:97 H261/90000 a=rtpmap:97 H261/90000
]]></sourcecode>
]]></artwork> <t>
</figure> RFC 4961 specifies a way of doing symmetric RTP, but that is a later
<t> extension to RTP, and Bob cannot assume that Alice supports RFC 4961. Th
RFC 4961 specifies a way of doing symmetric RTP but that is a later is
extension to RTP and Bob can not assume that Alice supports RFC 4961. Th
is
means that Alice may be sending RTP from a different port than 10000 or means that Alice may be sending RTP from a different port than 10000 or
10002 - some implementations simply send the RTP from an ephemeral 10002 -- some implementations simply send the RTP from an ephemeral
port. When Bob's endpoint receives an RTP packet, the only way that Bob port. When Bob's endpoint receives an RTP packet, the only way that Bob
knows if the packet is to be passed to the video or audio codec is by lo oking at knows if the packet is to be passed to the video or audio codec is by lo oking at
the port it was received on. This led some SDP implementations to use th the port it was received on.
e This prompted some SDP implementations to use a port number as an index
fact that each "m=" section had a different port number to use that port to find the
number as an index to find the correct m line in the SDP. As a result, s correct "m=" line in the SDP, since each "m"= section contains a differe
ome nt port number. As a result, some
implementations that do support symmetric RTP and ICE still use an SDP d ata implementations that do support symmetric RTP and ICE still use an SDP d ata
structure where SDP with "m=" sections with the same port such as: structure where SDP with "m=" sections with the same port such as:
</t> </t>
<figure> <t keepWithNext="true">SDP Offer</t>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
m=audio 10000 RTP/AVP 97 m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 98 m=video 10000 RTP/AVP 98
a=rtpmap:98 H261/90000 a=rtpmap:98 H261/90000
]]></sourcecode>
]]></artwork> <t>
</figure>
<t>
will result in the second "m=" section being considered an SDP error will result in the second "m=" section being considered an SDP error
because it has the same port as the first line. because it has the same port as the first line.
</t> </t>
</section> </section>
<section toc="default" numbered="true">
<section title="Usage of Port Number Value Zero" toc="default"> <name>Usage of Port Number Value Zero</name>
<t> <t>
In an SDP Offer or SDP Answer, the media specified by an "m=" section ca n be In an SDP Offer or SDP Answer, the media specified by an "m=" section ca n be
disabled/rejected by setting the port number value to zero. This is diff erent disabled/rejected by setting the port number value to zero. This is diff erent
from e.g., using the SDP direction attributes, where RTCP traffic will from, e.g., using the SDP direction attributes, where RTCP traffic will
continue even if the SDP "inactive" attribute is indicated for the continue even if the SDP 'inactive' attribute is indicated for the
associated "m=" section. associated "m=" section.
</t> </t>
<t> <t>
If each "m=" section associated with a BUNDLE group would contain differ ent If each "m=" section associated with a BUNDLE group would contain differ ent
port values, and one of those port values would be used for a BUNDLE add ress:port port values, and one of those port values would be used for a BUNDLE add ress:port
associated with the BUNDLE group, problems would occur if an endpoint wa nts to associated with the BUNDLE group, problems would occur if an endpoint wa nts to
disable/reject the "m=" section associated with that port, by setting th e port disable/reject the "m=" section associated with that port, by setting th e port
value to zero. After that, no "m=" section would contain the port value which value to zero. After that, no "m=" section would contain the port value that
is used for the BUNDLE address:port. In addition, it is unclear what wou ld happen is used for the BUNDLE address:port. In addition, it is unclear what wou ld happen
to the ICE candidates associated with the "m=" section, as they are also used for to the ICE candidates associated with the "m=" section, as they are also used for
the BUNDLE address:port. the BUNDLE address:port.
</t> </t>
</section> </section>
<section toc="default" numbered="true">
<section title="B2BUA And Proxy Interoperability" toc="default"> <name>B2BUA and Proxy Interoperability</name>
<t> <t>
Some back to back user agents may be configured in a mode where if Some back-to-back user agents may be configured in a mode where if
the incoming call leg contains an SDP attribute the B2BUA does not the incoming call leg contains an SDP attribute the B2BUA does not
understand, the B2BUA still generates that SDP attribute in the Offer understand, the B2BUA still generates that SDP attribute in the Offer
for the outgoing call leg. Consider a B2BUA that did not understand for the outgoing call leg. Consider a B2BUA that did not understand
the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. the SDP 'rtcp' attribute, defined in RFC 3605, yet acted this way.
Further assume that the B2BUA was configured to tear down any call Further assume that the B2BUA was configured to tear down any call
where it did not see any RTCP for 5 minutes. In this case, if the B2BUA where it did not see any RTCP for 5 minutes. In this case, if the B2BUA
received an Offer like: received an Offer like:
</t> </t>
<figure> <t keepWithNext="true">SDP Offer</t>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer
<sourcecode type="sdp"><![CDATA[
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=rtcp:53020 a=rtcp:53020
]]></sourcecode>
]]></artwork>
</figure>
<t> <t>
It would be looking for RTCP on port 49171 but would not see any It would be looking for RTCP on port 49171 but would not see any
because the RTCP would be on port 53020 and after five minutes, it would because the RTCP would be on port 53020, and after five minutes, it would
tear down the call. Similarly, a B2BUA that did not understand BUNDLE yet tear down the call. Similarly, a B2BUA that did not understand BUNDLE yet
put BUNDLE in its offer may be looking for media on the wrong port and put it in its offer may be looking for media on the wrong port and
tear down the call. It is worth noting that a B2BUA that generated an tear down the call. It is worth noting that a B2BUA that generated an
Offer with capabilities it does not understand is not compliant with the Offer with capabilities it does not understand is not compliant with the
specifications. specifications.
</t> </t>
<section toc="default" numbered="true">
<section title="Traffic Policing" toc="default"> <name>Traffic Policing</name>
<t> <t>
Sometimes intermediaries do not act as B2BUAs, in the sense that Sometimes intermediaries do not act as B2BUAs, in the sense that
they don't modify SDP bodies, nor do they terminate SIP dialogs. they don't modify SDP bodies nor do they terminate SIP dialogs.
Still, however, they may use SDP information (e.g., IP address and However, they may still use SDP information (e.g., IP address and
port) in order to control traffic gating functions, and to set port) in order to control traffic gating functions and to set
traffic policing rules. There might be rules which will trigger traffic policing rules. There might be rules that will trigger
a session to be terminated in case media is not sent or received a session to be terminated in case media is not sent or received
on the ports retrieved from the SDP. This typically occurs once the on the ports retrieved from the SDP. This typically occurs once the
session is already established and ongoing. session is already established and ongoing.
</t> </t>
</section> </section>
<section title="Bandwidth Allocation" toc="default"> <section toc="default" numbered="true">
<t> <name>Bandwidth Allocation</name>
Sometimes intermediaries do not act as B2BUAs, in the sense that <t>
they don't modify SDP bodies, nor do they terminate SIP dialogs. Sometimes, intermediaries do not act as B2BUAs, in the sense that
Still, however, they may use SDP information (e.g., codecs and they don't modify SDP bodies nor do they terminate SIP dialogs.
However, they may still use SDP information (e.g., codecs and
media types) in order to control bandwidth allocation functions. media types) in order to control bandwidth allocation functions.
The bandwidth allocation is done per "m=" section, which means that The bandwidth allocation is done per "m=" section, which means that
it might not be enough if media specified by all "m=" sections it might not be enough if media specified by all "m=" sections
try to use that bandwidth. That may either simply lead to bad try to use that bandwidth. That may simply lead to either bad
user experience, or to termination of the call. user experience or termination of the call.
</t> </t>
</section>
</section> </section>
</section> <section toc="default" numbered="true">
<name>Candidate Gathering</name>
<section title="Candidate Gathering" toc="default"> <t>
<t>
When using ICE, a candidate needs to be gathered for each port. This When using ICE, a candidate needs to be gathered for each port. This
takes approximately 20 ms extra for each extra "m=" section due to the N AT takes approximately 20 ms extra for each extra "m=" section due to the N AT
pacing requirements. All of this gathering can be overlapped with other pacing requirements. All of this gathering can be overlapped with other
things while e.g., a web-page is loading to minimize the impact. If the things while, e.g., a web page is loading to minimize the impact. If the
client client
only wants to generate TURN or STUN ICE candidates for one of the "m=" only wants to generate Traversal Using Relays around NAT (TURN) or STUN
lines and then use trickle ICE <xref target="I-D.ietf-ice-trickle"/> ICE candidates for one of the "m="
to get the non host ICE candidates for the rest of the "m=" sections, it lines and then use Trickle ICE <xref target="RFC8838" format="default"/>
MAY do to get the non-host ICE candidates for the rest of the "m=" sections, it
<bcp14>MAY</bcp14> do
that and will not need any additional gathering time. that and will not need any additional gathering time.
</t> </t>
<t> <t>
Some people have suggested a TURN extension to get a bunch of TURN Some people have suggested a TURN extension to get a bunch of TURN
allocations at once. This would only provide a single STUN result so in allocations at once. This would only provide a single STUN result, so in
cases where the other end did not support BUNDLE, it may cause more use of cases where the other end did not support BUNDLE, it may cause more use of
the TURN server but would be quick in the cases where both sides the TURN server, but it would be quick in the cases where both sides
supported BUNDLE and would fall back to a successful call in the other supported BUNDLE and would fall back to a successful call in the other
cases. cases.
</t>
</section>
<section anchor="sec-acks" toc="default" numbered="false">
<name>Acknowledgements</name>
<t>
The usage of the SDP grouping extension for negotiating bundled media is
based on similar alternatives proposed by <contact fullname="Harald
Alvestrand"/> and <contact fullname="Cullen Jennings"/>. The BUNDLE
extension described in this document is based on the different
alternative proposals, and text (e.g., SDP examples) has been borrowed
(and, in some cases, modified) from those alternative proposals.
</t>
<t>
The SDP examples are also modified versions from the ones in the Alvestran
d
proposal.
</t>
<t>
Thanks to <contact fullname="Paul Kyzivat"/>, <contact fullname="Martin
Thomson"/>, <contact fullname="Flemming Andreasen"/>, <contact
fullname="Thomas Stach"/>, <contact fullname="Ari Keränen"/>, <contact
fullname="Adam Roach"/>, <contact fullname="Christian Groves"/>,
<contact fullname="Roman Shpount"/>, <contact fullname="Suhas
Nandakumar"/>, <contact fullname="Nils Ohlmeier"/>, <contact
fullname="Jens Guballa"/>, <contact fullname="Raju Makaraju"/>, <contact
fullname="Justin Uberti"/>, <contact fullname="Taylor Brandstetter"/>,
<contact fullname="Byron Campen"/>, and <contact fullname="Eric
Rescorla"/> for reading the text and providing useful feedback.
</t>
<t>
Thanks to <contact fullname="Bernard Aboba"/>, <contact fullname="Peter
Thatcher"/>, <contact fullname="Justin Uberti"/>, and <contact
fullname="Magnus Westerlund"/> for providing the text for the section on
RTP/RTCP stream association.
</t>
<t>
Thanks to <contact fullname="Magnus Westerlund"/>, <contact
fullname="Colin Perkins"/>, and <contact fullname="Jonathan Lennox"/>
for providing help and text on the RTP/RTCP procedures.
</t>
<t>
Thanks to <contact fullname="Charlie Kaufman"/> for performing the Sec-Di
r review.
</t>
<t>
Thanks to <contact fullname="Linda Dunbar"/> for performing the Gen-ART r
eview.
</t>
<t>
Thanks to Spotify for providing music for the countless hours of
document editing.
</t> </t>
</section> </section>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 446 change blocks. 
2461 lines changed or deleted 2117 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/