One document matched: draft-ietf-mmusic-sdp-bundle-negotiation-05.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200902" category="std" docName="draft-ietf-mmusic-sdp-bundle-negotiation-05.txt" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="Bundled media">
Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers
</title>
<author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<author fullname="Harald Tveit Alvestrand" surname="Alvestrand" initials="H. T.">
<organization>Google</organization>
<address>
<postal>
<street>Kungsbron 2</street>
<city>Stockholm</city>
<code>11122</code>
<country>Sweden</country>
</postal>
<email>harald@alvestrand.no</email>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>400 3rd Avenue SW, Suite 350</street>
<city>Calgary</city>
<region>AB</region>
<code>T2P 4H2</code>
<country>Canada</country>
</postal>
<email>fluffy@iii.ca</email>
</address>
</author>
<date year="2013" />
<area>Transport</area>
<workgroup>MMUSIC Working Group</workgroup>
<keyword>RTP</keyword>
<keyword>SDP</keyword>
<keyword>Bundle</keyword>
<keyword>Multiplexing</keyword>
<keyword>RTCWEB</keyword>
<keyword>CLUE</keyword>
<keyword>RTCWEB</keyword>
<keyword>MMUSIC</keyword>
<keyword>AVT</keyword>
<keyword>WEB</keyword>
<keyword>Browser</keyword>
<abstract>
<t>
This specification defines a new SDP Grouping Framework extension, "BUNDLE",
that can be used with the Session Description Protocol (SDP) Offer/Answer
mechanism to negotiate the usage of bundled media, which refers to the usage
of a single 5-tuple for media associated with multiple SDP media descriptions
("m=" lines).
</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>
In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and receiving media
associated with multiple SDP media descriptions ("m=" lines) has been identified. This
would e.g. allow the usage of a single set of Interactive Connectivity Establishment
(ICE) <xref format="default" pageno="false" target="RFC5245"/> candidates for multiple
media descriptions. Normally different media types (audio, video etc) will be described
using different media descriptions.
</t>
<t>
This specification defines a new SDP Grouping Framework <xref format="default" pageno="false"
target="RFC5888"/> extension, "BUNDLE", that can be used with the Session Description
Protocol (SDP) Offer/Answer mechanism <xref format="default" pageno="false" target="RFC3264"/>
to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for
media associated with multiple SDP media descriptions ("m=" lines).
</t>
<t>
The Offerer and Answerer <xref format="default" pageno="false" target="RFC3264"/> use
the BUNDLE mechanism to negotiate a single BUNDLE address to be used for the bundled
media associated with a BUNDLE group.
</t>
<t>
The BUNDLE mechanism allows an SDP Offerer and SDP Answerer to assign identical addresses
to multiple "m=" lines, if those "m=" lines are associated with a BUNDLE group. However,
until it is known whether both the Offerer and Answerer support the BUNDLE mechanism,
unique addresses are assigned to each "m=" line, including those associated with a BUNDLE group.
</t>
<t>
NOTE: As defined in RFC 4566 <xref format="default" pageno="false" target="RFC4566"/>, the
semantics of multiple "m=" lines using the same port number value are undefined, and
there is no grouping defined by such means. Instead, an explicit grouping mechanism needs
to be used to express the intended semantics. This specification provides such extension.
</t>
<t>
SDP Offers and SDP Answer can contain multiple BUNDLE groups. For each BUNDLE group,
a BUNDLE address is negotiated. Multiple BUNDLE groups cannot share the same bundle
address.
</t>
<t>
The default assumption is that all Real-Time Protocol (RTP) <xref format="default"
pageno="false" target="RFC3550"/> based media flows within a BUNDLE group belongs to the
same RTP Session <xref format="default" pageno="false" target="RFC3550"/>. Future
extensions can change that assumption.
</t>
<t>
The BUNDLE mechanism is backward compatible. Endpoints that do not support the BUNDLE mechanism
are expected to generate SDP Offers and SDP Answers without an SDP group:BUNDLE attribute, and
are expected to assign unique addresses to each "m=" line, according to the procedures in
<xref format="default" pageno="false" target="RFC4566"/> and <xref format="default"
pageno="false" target="RFC3264"/>
</t>
</section>
<section title="Terminology" toc="default">
<t>
5-tuple: A collection of the following values: source address, source port,
destination address, destination port and protocol.
</t>
<t>
Bundled media: Two or more RTP streams using a single 5-tuple. The RTCP
streams associated with the RTP streams also use a single 5-tuple, which might
be the same, but can also be different, as the one used by the RTP streams.
</t>
<t>
Unique address: This refers to an IP address and IP port
combination, that can only be associated with a single "m=" line within an
SDP Session.
</t>
<t>
BUNDLE address: This refers to an IP address and IP port combination, that
is associated with each "m=" line within a BUNDLE group, within an SDP Session.
The zero IP port value BUNDLE address MUST NOT be used in a BUNDLE address.
</t>
<t>
NOTE: "m=" lines that share a BUNDLE address MUST also share other parameters
related to the media transport plane, e.g. ICE candidate information.
</t>
</section>
<section title="Conventions" toc="default">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 <xref
format="default" pageno="false" target="RFC2119" />.
</t>
</section>
<section title="Applicability Statement" toc="default">
<t>
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"/>.
</t>
</section>
<section title="SDP Grouping Framework BUNDLE Extension Semantics" toc="default">
<t>
This section defines a new SDP Grouping Framework extension, BUNDLE.
</t>
<t>
The BUNDLE extension can be indicated using an SDP session-level 'group'
attribute. Each SDP Media Description ("m=" line) that is grouped together,
using SDP media-level mid attributes, belongs to a given BUNDLE
group.
</t>
</section>
<section title="SDP Offer/Answer Procedures" anchor="sec-oa" toc="default">
<section title="General" anchor="sec-oa-gen" toc="default">
<t>
This section describes the usage of the SDP Offer/Answer mechanism
<xref format="default" pageno="false" target="RFC3264"/> to negotiate the
usage of the BUNDLE mechanism, to negotiate the BUNDLE address, and
to add, remove and reject SDP Media Descriptions ("m=" lines)
<xref format="default" pageno="false" target="RFC4566"/> associated
with a BUNDLE group.
</t>
<t>
The generic rules and procedures defined in <xref format="default" pageno="false"
target="RFC3264"/> and <xref format="default" pageno="false"
target="RFC5888"/> apply when the SDP Offer/Answer mechanism is used with the BUNDLE
mechanism. For example, if an SDP Offer is rejected, the previously negotiated SDP
parameters and characteristics (including those associated with BUNDLE groups) apply.
</t>
<t>
When an endpoint, acting as an Offerer or Answerer <xref format="default" pageno="false"
target="RFC3264"/>, generates an SDP Offer, or an SDP Answer, the endpoint MUST assign
an SDP media-level mid value for each "m=" line in a BUNDLE group. In addition, the
endpoint MUST assign an SDP session-level group:BUNDLE attribute for each BUNDLE group,
and place each mid associated with the SDP group:BUNDLE attribute mid list.
</t>
</section>
<section title="Bundled SDP Information" anchor="sec-oa-sdp" toc="default">
<section title="General" anchor="sec-oa-sdp-gen" toc="default">
<t>
This section describes restrictions associated with the usage of
SDP parameters and extensions within a BUNDLE group. It also
describes, when parameter and attribute values have been
assigned to each "m=" line in the BUNDLE group, how to calculate
a value for the whole BUNDLE group.
</t>
</section>
<section title="Bandwidth (b=)" anchor="sec-oa-sdp-b" toc="default">
<t>
The total proposed bandwidth is the sum of the proposed bandwidth for each
"m=" line associated with a negotiated BUNDLE group.
</t>
</section>
<section title="rtcp-mux Attribute" anchor="sec-oa-sdp-rtcpmux" toc="default">
<t>
For each "m=" line in a BUNDLE group, an Offerer and Answerer MUST assign
an SDP rtcp-mux attribute <xref format="default" pageno="false"
target="RFC5761"/>.
</t>
</section>
<section title="rtcp Attribute" anchor="sec-oa-sdp-rtcp" toc="default">
<t>
When used, for each RTP media "m=" line in a BUNDLE group, an Offerer and Answerer MUST
assign an SDP rtcp attribute <xref format="default" pageno="false" target="RFC3605"/>
with an identical attribute value.
</t>
</section>
<section title="DTLS-SRTP fingerprint Attribute" anchor="sec-oa-sdp-fingerprint" toc="default">
<t>
When DTLS-SRTP is used, for each RTP media "m=" line in a BUNDLE group, an Offerer and Answerer
MUST assign an SDP DTLS-SRTP fingerprint attribute with identical attribute values.
</t>
</section>
<section title="SDES crypto Attribute" anchor="sec-oa-sdp-crypto" toc="default">
<t>
When SDES is used, for each RTP media "m=" line in a BUNDLE group, an Offerer and Answerer
MUST assign an SDP crypto attribute, with unique attribute values.
</t>
</section>
<section title="Other Attributes (a=)" anchor="sec-oa-sdp-a" toc="default">
<t>
There are also special rules for handling many different attributes as defined
in <xref target="I-D.nandakumar-mmusic-sdp-mux-attributes" />. It might not possible
to use bundle with some attributes.
</t>
</section>
</section>
<section title="RFC 5888 restrictions" anchor="sec-oa-5888" toc="default">
<t>
Based on the rules and procedures in <xref target="RFC5888" pageno="false" format="default"/>, the
following restrictions also apply to BUNDLE groups in SDP Answers:
<list style="symbols">
<t>
1) A BUNDLE group must not be added to an SDP Answer, unless the same BUNDLE group was
included in the associated SDP Offer; and
</t>
<t>
2) An SDP "m=" line must not be added to a BUNDLE group in the SDP Answer, unless it
was in the same BUNDLE group in the associated SDP Offer.
</t>
</list>
</t>
</section>
<section title="SDP Offerer Procedures" anchor="sec-oa-off" toc="default">
<section title="General" anchor="sec-oa-off-gen" toc="default">
<t>
When an Offerer generates an Offer, it assigns an address to each
"m=" line, according to the procedures in <xref target="RFC3264"
pageno="false" format="default"/>. To each "m=" line within a
BUNDLE group the Offerer assigns either an address that is unique
to that "m=" line, or a shared address that is also assigned to
other "m=" lines within the BUNDLE group. Such shared address can
be, but does not have to be, a previously selected BUNDLE
address <xref format="default" pageno="false" target="sec-oa-ans-off"/>.
</t>
<t>
OPEN ISSUE (Q6): There is a discussion on whether assigning a shared
address to multiple "m=" lines shall be allowed until the Answerer
has indicated support of BUNDLE.
<list style="symbols">
<t>(http://www.ietf.org/mail-archive/web/mmusic/current/msg12245.html)</t>
</list>
</t>
<t>
The Offerer MUST NOT assign an address (unique or shared), that it
has assigned to an "m=" line within a BUNDLE group, to an "m=" line
outside the BUNDLE group.
</t>
<t>
The Offerer MUST, for a BUNDLE group, on the SDP session level
<xref target="RFC4566" pageno="false" format="default"/>, insert
an SDP group:BUNDLE attribute associated with the BUNDLE group.
The Offerer MUST assign an SDP 'mid' attribute <xref target="RFC5888"
pageno="false" format="default"/> to each "m=" line within the BUNDLE
group, and place the mid value in the group:BUNDLE attribute mid list.
</t>
<t>
The Offerer MAY assign an SDP 'bundle-only' attribute [ref-to-be-added]
to one or more "m=" lines within a BUNDLE group.
</t>
<t>
OPEN ISSUE (Q8): It still needs to be decided whether a zero port
value can be assigned to a 'bundle-only' "m=" line.
<list style="symbols">
<t>(http://www.ietf.org/mail-archive/web/mmusic/current/msg12075.html)</t>
<t>(http://www.ietf.org/mail-archive/web/mmusic/current/msg12226.html)</t>
<t>(http://www.ietf.org/mail-archive/web/mmusic/current/msg12339.html)</t>
</list>
</t>
</section>
<section title="Request BUNDLE address selection" anchor="sec-oa-off-req" toc="default">
<t>
When an Offerer generates an Offer, it MUST indicate which address
(unique or shared) within a BUNDLE group it wishes the Answer to
select as the Offerer's BUNDLE address for the BUNDLE group
<xref format="default" pageno="false" target="sec-oa-ans-off"/>. The
Offerer MUST do this even if the Answerer has, in a previous Answer
within the dialog, already selected the Offerer's BUNDLE address.
</t>
<t>
In order to request an address (unique or shared) to be selected as
the Offerer's BUNDLE address for a BUNDLE group, the Offerer places
the mid value, associated with the "m=" line representing the
requested address, first in the SDP group:BUNDLE attribute mid list
associated with the BUNDLE group.
</t>
<t>
<xref target="sec-example-add" pageno="false" format="default"/> shows an example of a Bundle
Address Request.
</t>
</section>
<section title="Bundle Address Synchronization (BAS)" anchor="sec-oa-off-bas" toc="default">
<t>
When an Offerer receives an Answer, in which an offered BUNDLE group
is accepted, if the Offerer in the associated Offer assigned an
address (unique or shared), that does not represent the BUNDLE
address selected for the Offerer, to an "m=" line within the BUNDLE
group, the Offerer MUST send a subsequent Offer, in which it assigns
the BUNDLE address selected for the Offerer to each "m=" line within
the BUNDLE group. This procedure is referred to as Bundle Address
Synchronization (BAS), and the Offer is referred to as a BAS Offer.
</t>
<t>
The Offerer MAY modify any SDP parameter in a BAS Offer.
</t>
<t>
NOTE: It is important that the BAS Offer gets accepted by the
Answerer, so the Offerer needs to consider the necessity to modify
SDP parameters that could get the Answerer to reject the BAS Offer.
Removing "m=" lines, or reducing the number of codecs, in the BAS
Offer used for the is considered to have a low risk of being
rejected.
</t>
<t>
NOTE: The main purpose of the BAS Offer is to make sure that
intermediaries, that might not support the BUNDLE mechanism, have
correct information regarding which address is going to be used for
the bundled media.
</t>
<t>
<xref target="sec-example-add" pageno="false" format="default"/>
shows an example of an BAS Offer.
</t>
</section>
<section title="Adding a media description to a BUNDLE group" anchor="sec-oa-off-add" toc="default">
<t>
When an Offerer generates an Offer, in which it adds an "m=" line to
a BUNDLE group, the Offerer assigns an address (unique or shared) to
the "m=" line, assigns an SDP 'mid' attribute to the "m=" line, and
places the mid value in the group:BUNDLE attribute mid list
associated with the BUNDLE group, according to the procedures in
<xref format="default" pageno="false" target="sec-oa-off-req"/>.
If the Offerer wishes the Answerer to select the address assigned to
the added "m=" as the Offerer's BUNDLE address, the mid value associated
with the "m=" line is placed first in the list, according to the procedures
in <xref format="default" pageno="false" target="sec-oa-off-req"/>.
</t>
<t>
<xref target="sec-example-off-add" pageno="false" format="default"/>
shows an example of an Offer used to add an "m=" line to a BUNDLE group.
</t>
</section>
<section title="Moving A Media Description Out Of A BUNDLE Group" anchor="sec-oa-off-rem" toc="default">
<t>
When an Offerer generates an Offer, in which an "m=" line is moved
out of a BUNDLE group, the Offerer MUST assign a unique address to
the moved "m=" line. In addition, the Offerer MUST NOT anymore
include a mid value, representing the "m=" line, in the SDP
group:BUNDLE attribute mid list associated with the BUNDLE group.
</t>
<t>
<xref target="sec-example-off-mov" pageno="false" format="default"/>
shows an example of an Offer used to move an "m=" line out of a BUNDLE group.
</t>
</section>
<section title="Disabling A Media Description In A BUNDLE Group" anchor="sec-oa-off-rej" toc="default">
<t>
When an Offerer generates an Offer, in which an "m=" line associated
with a BUNDLE group is disabled, the Offerer MUST assign an address
with a zero port value <xref target="RFC4566" pageno="false" format="default"/>
to the disabled "m=" line. In addition, the Offerer MUST NOT anymore
include a mid value, representing the "m=" line, in the SDP group:BUNDLE
attribute mid list associated with the BUNDLE group.
</t>
<t>
OPEN ISSUE (Q8): It still needs to be decided whether a zero port
value can be assigned to a 'bundle-only' "m=" line.
<list style="symbols">
<t>(http://www.ietf.org/mail-archive/web/mmusic/current/msg12075.html)</t>
<t>(http://www.ietf.org/mail-archive/web/mmusic/current/msg12226.html)</t>
<t>(http://www.ietf.org/mail-archive/web/mmusic/current/msg12339.html)</t>
</list>
</t>
<t>
<xref target="sec-example-off-dis" pageno="false" format="default"/>
shows an example of an Offer used to disable an "m=" line in a BUNDLE group.
</t>
</section>
</section>
<section title="SDP Answerer Procedures" anchor="sec-oa-ans" toc="default">
<section title="Offerer Bundle Address Selection" anchor="sec-oa-ans-off" toc="default">
<t>
When an Answerer generates an Answer that contains a BUNDLE group,
the Answer MUST select the Offerer's BUNDLE address. The first mid
value in the SDP group:BUNDLE attribute mid list of the Offer
represents the address which the Offerer wishes the Answer to
select as the Offerer's BUNDLE address <xref target="sec-oa-off-req"
pageno="false" format="default"/>.
</t>
<t>
The Answerer SHOULD select the address represented by the first mid
value, unless the Answerer in the associated Answer will reject the
"m=" line associated with the mid value, or remove the "m=" line
from the BUNDLE group. In such case the Answerer MUST select an
address associated with the first unrejected mid value that remains
in the SDP group:BUNDLE attribute mid list of the Offer.
</t>
<t>
In the SDP Answer, the Answerer MUST place the mid value associated with
the selected Offerer's BUNDLE address first in the SDP group:BUNDLE
attribute mid list associated with the BUNDLE group.
</t>
<t>
<xref target="sec-example-add" pageno="false" format="default"/> shows an example of an
Offerer's BUNDLE address selection.
</t>
</section>
<section title="Anwerer Bundle Address Selection" anchor="sec-oa-ans-ans" toc="default">
<t>
When an Answerer creates an Answer that contains a BUNDLE group,
the Answerer MUST assign a local shared address, the Answerer's BUNDLE
address, to each "m=" line within the BUNDLE group.
</t>
<t>
The Answerer is allowed to change its BUNDLE address in any SDP
Answer.
</t>
<t>
The Answerer MUST NOT assign a shared address, that it has assigned
to an "m=" line within a BUNDLE group, to an "m=" line outside
the BUNDLE group.
</t>
<t>
<xref target="sec-example-add" pageno="false" format="default"/> shows an example of an
Answerer's local BUNDLE address selection.
</t>
</section>
<section title="Moving A Media Description Out Of A BUNDLE Group" anchor="sec-oa-ans-rem" toc="default">
<t>
When an Answerer generates an Answer, in which an "m=" line is moved
out of a BUNDLE group, the Answerer assigns an address to the moved
"m=" line based on the type of address that the Offerer assigned
to the associated "m=" line in the associated Offer, as described below.
</t>
<t>
If the Offerer assigned a shared address to the "m=" line, the
answerer MUST reject the moved "m=" line, according to the procedures
in <xref target="sec-oa-ans-rej" pageno="false" format="default"/>.
</t>
<t>
If the Offerer assigned an SDP 'bundle-only' attribute to the "m=" line,
the Answerer MUST reject the moved "m=" line, according to the procedures
in <xref target="sec-oa-ans-rej" pageno="false" format="default"/>.
</t>
<t>
If the Offerer assigned a unique address to the "m=" line, the Answer
MUST assign a unique address to the moved "m=" line.
</t>
<t>
In addition, in either case above, the Answerer MUST NOT anymore
include a mid value, representing the "m=" line, in the SDP
group:BUNDLE attribute list associated with the BUNDLE group.
</t>
</section>
<section title="Rejecting A Media Description In A BUNDLE Group" anchor="sec-oa-ans-rej" toc="default">
<t>
When an Answerer generates an Answer, in which an "m=" line associated
with a BUNDLE group is rejected, the Answerer MUST assign an address
with a zero port value to the rejected "m=" line, according to the
procedures in <xref target="RFC4566" pageno="false" format="default"/>.
In addition, the Answerer MUST NOT anymore include a mid value, representing
the "m=" line, in the SDP group:BUNDLE attribute midlist associated with the BUNDLE group.
</t>
</section>
</section>
</section>
<section anchor="sec-rtp" title="Single vs Multiple RTP Sessions" toc="default">
<section title="General" toc="default">
<t>
By default, all RTP based media flows within a given BUNDLE group belong to a single RTP session
<xref format="default" pageno="false" target="RFC3550"/>. Multiple BUNDLE groups will form
multiple RTP Sessions.
</t>
<t>
The usage of multiple RTP Sessions within a given BUNDLE group, or the usage of a single
RTP Session that spans over multiple BUNDLE groups, is outside the scope of this specification.
Other specification needs to extend the BUNDLE mechanism in order to allow such usages.
</t>
</section>
<section title="Single RTP Session" toc="default">
<t>
When a single RTP Session is used, media associated with all "m=" lines part
of a bundle group share a single SSRC <xref format="default" pageno="false"
target="RFC3550"/> numbering space.
</t>
<t>
In addition, the following rules and restrictions apply for a single RTP
Session:
</t>
<t>
<list style="symbols">
<t>The dynamic payload type values used in the "m=" lines MUST NOT overlap.</t>
<t>The "proto" value in each "m=" line MUST be identical (e.g. RTP/AVPF).</t>
<t>A given SSRC SHOULD NOT transmit RTP packets using payload types that
originates from different "m=" lines.</t>
</list>
</t>
<t>
NOTE: The last bullet above is to avoid sending multiple media types from the same SSRC.
If transmission of multiple media types are done with time overlap RTP and RTCP fails
to function. Even if done in proper sequence this causes RTP Timestamp rate switching
issues [ref to draft-ietf-avtext-multiple-clock-rates].
</t>
</section>
</section>
<section title="Usage With ICE" anchor="sec-ice" toc="default">
<section title="General" anchor="sec-ice-gen" toc="default">
<t>
This section describes how to use the BUNDLE grouping extension together
with the Interactive Connectivity Establishment (ICE) mechanism <xref
format="default" pageno="false" target="RFC5245"/>.
</t>
</section>
<section title="Candidates" anchor="sec-ice-can" toc="default">
<t>
When an ICE-enabled endpoint generates an SDP Offer, which contains a BUNDLE group,
the SDP Offerer MUST include ICE candidates for each "m=" line associated with a "BUNDLE"
group, except for any "m=" line with a zero port number value. If the "m=" lines associated
with the BUNDLE group contain different port number values, the SDP Offerer MUST also
insert different candidate values in each "m=" line associated with the BUNDLE group.
If the "m=" lines associated with the BUNDLE group contain an identical port number
value, the candidate values MUST also be identical.
</t>
<t>
When an ICE-enabled endpoint generates and SDP Answer, which contains a BUNDLE group,
the Answerer MUST include ICE candidates for each "m=" line associated with the "BUNDLE"
group, except for any "m=" line where the port number value is set to zero. The Answerer
MUST insert identical candidate values in each "m=" line associated with the BUNDLE group.
</t>
</section>
<section title="Candidates" anchor="sec-ice-con-checks" toc="default">
<t>
Once it is known that both endpoints support, and accept to use, the BUNDLE grouping
extension, ICE connectivity checks and keep-alives only needs to be performed for the
whole BUNDLE group, instead of for each individual "m=" line associated with the group.
</t>
</section>
</section>
<section title="Security Considerations" anchor="sec-security" toc="default">
<t>
This specification does not significantly change the security
considerations of SDP which can be found in Section X of TBD.
</t>
<t>
TODO: Think carefully about security analysis of reuse of same SDES
key on multiple "m=" lines when the far end does not use BUNDLE and
warn developers of any risks.
</t>
</section>
<section title="Examples" anchor="sec-example-alt1" toc="default">
<section title="Example: Bundle Address Selection" anchor="sec-example-add" toc="default">
<t>
The example below shows:
<list style="symbols">
<t>1. An SDP Offer, in which the Offerer assigns unique addresses to each "m=" line in the BUNDLE group, and requests the Answerer to select the Offerer's BUNDLE address.</t>
<t>2. An SDP Answer, in which the Answerer selects the BUNDLE address for the Offerer, and assigns its own local BUNDLE address to each "m=" line in the BUNDLE group.</t>
<t>3. A subsequent SDP Offer, which is used to perform a Bundle Address Synchronization (BAS).</t>
</list>
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer (1)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
SDP Answer (2)
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
SDP Offer (3)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
]]></artwork>
</figure>
</section>
<section title="Example: Bundle Mechanism Rejected" anchor="sec-example-bunrej" toc="default">
<t>
The example below shows:
<list style="symbols">
<t>1. An SDP Offer, in which the Offerer assigns unique addresses to each "m=" line in the BUNDLE group, and requests the Answerer to select the Offerer's BUNDLE address.</t>
<t>2. An SDP Answer, in which the Answerer rejects the BUNDLE group, and assigns unique addresses to each "m=" line.</t>
</list>
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer (1)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
SDP Answer (2)
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 20000 RTP/AVP 0
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32
b=AS:1000
a=rtpmap:32 MPV/90000
]]></artwork>
</figure>
</section>
<section title="Example: Offerer Adds A Media Description To A BUNDLE Group" anchor="sec-example-off-add" toc="default">
<t>
The example below shows:
<list style="symbols">
<t>1. An SDP Offer, in which the Offerer adds an "m=" line, represented by the "zen" mid value, to a previously negotiated BUNDLE group,
assigns a unique address to the added "m=" line, and assigns the previously negotiated BUNDLE address to the previously added "m="
lines in the BUNDLE group.</t>
<t>2. An SDP Answer, in which the Answerer assigns its own local BUNDLE address to each "m=" line (including the added "m=" line) in
the BUNDLE group.</t>
<t>3. A subsequent SDP Offer, which is used to perform a Bundle Address Synchronization (BAS).</t>
</list>
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer (1)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar zen
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
m=video 20000 RTP/AVP 66
a=mid:zen
b=AS:1000
a=rtpmap:66 H261/90000
SDP Answer (2)
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE foo bar zen
m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
m=video 20000 RTP/AVP 66
a=mid:zen
b=AS:1000
a=rtpmap:66 H261/90000
SDP Offer (3)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar zen
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
m=video 10000 RTP/AVP 66
a=mid:zen
b=AS:1000
a=rtpmap:66 H261/90000
]]></artwork>
</figure>
</section>
<section title="Example: Offerer Moves A Media Description Out Of A BUNDLE Group" anchor="sec-example-off-mov" toc="default">
<t>
The example below shows:
<list style="symbols">
<t>1. An SDP Offer, in which the Offerer moves an "m=" line out of a previously negotiated BUNDLE group, assigns a unique address to
the moved "m=" line, and assigns the previously negotiated BUNDLE address to the remaining "m=" lines in the BUNDLE group.</t>
<t>2. An SDP Answer, in which the Answerer moves the corresponding "m=" line out of the BUNDLE group, and assigns unique address to
the moved "m=" line, and assigns the previously negotiated BUNDLE address to the remaining "m=" lines in the BUNDLE group.</t>
</list>
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer (1)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
m=video 50000 RTP/AVP 66
b=AS:1000
a=rtpmap:66 H261/90000
SDP Answer (2)
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
m=video 60000 RTP/AVP 66
b=AS:1000
a=rtpmap:66 H261/90000
]]></artwork>
</figure>
</section>
<section title="Example: Offerer Disables A Media Description In A BUNDLE Group" anchor="sec-example-off-dis" toc="default">
<t>
The example below shows:
<list style="symbols">
<t>1. An SDP Offer, in which the Offerer moves an "m=" line out of a previously negotiated BUNDLE group, assigns a zero port number
the moved "m=" line in order to disable it, and assigns the previously negotiated BUNDLE address to the remaining "m=" lines in the
BUNDLE group.</t>
<t>2. An SDP Answer, in which the Answerer moves the corresponding "m=" line out of the BUNDLE group, and assigns a zero port value
to the moved "m=" line in order to disable it, and assigns the previously negotiated BUNDLE address to the remaining "m=" lines in
the BUNDLE group.</t>
</list>
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer (1)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
m=video 0 RTP/AVP 66
a=rtpmap:66 H261/90000
SDP Answer (2)
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
m=video 0 RTP/AVP 66
a=rtpmap:66 H261/90000
]]></artwork>
</figure>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>
This document requests IANA to register the new SDP Grouping semantic
extension called BUNDLE.
</t>
</section>
<section anchor="sec-acks" title="Acknowledgements" toc="default">
<t>
The usage of the SDP grouping extension for negotiating bundled media is
based on a similar alternatives proposed by Harald Alvestrand and Cullen
Jennings. The BUNDLE mechanism 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 Alvestrand
proposal.
</t>
<t>
Thanks to Paul Kyzivat and Martin Thompson for taking the the time
to read the text along the way, and providing useful feedback.
</t>
</section>
<section title="Change Log">
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</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/mmusic/current/msg12293.html).</t>
<t>Updated Answerer procedures (http://www.ietf.org/mail-archive/web/mmusic/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 title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.5761"?>
<?rfc include="reference.RFC.5888"?>
<reference anchor="I-D.nandakumar-mmusic-sdp-mux-attributes">
<front>
<title abbrev="SDP Attribute Multiplexing">
A Framework for SDP Attributes when Multiplexing
</title>
<author fullname="Suhas Nandakumar" initials="S.N" surname="Nandakumar">
<organization>Cisco</organization>
<address>
</address>
</author>
<author fullname="Cullen Jennings" initials="C.J" surname="Jennings">
<organization>Cisco</organization>
<address>
</address>
</author>
<date day="24" month="September" year="2013" />
</front>
<seriesInfo name="Internet-Draft" value="draft-nandakumar-mmusic-sdp-mux-attributes-04" />
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.3605"?>
<?rfc include="reference.RFC.5245"?>
<reference anchor="I-D.ietf-mmusic-trickle-ice">
<front>
<title abbrev="Trickle ICE">
Trickle ICE: Incremental Provisioning of Candidates
for the Interactive Connectivity Establishment (ICE) Protocol
</title>
<author fullname="Emil Ivov" initials="E.I" surname="Ivov">
<organization>Jitsi</organization>
</author>
<author fullname="Eric Rescorla" initials="E.R" surname="Rescorla">
<organization>RTFM, Inc</organization>
</author>
<author fullname="Justin Uberti" initials="J.U" surname="Uberti">
<organization>Google</organization>
</author>
<date day="8" month="October" year="2013" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-trickle-ice-00" />
</reference>
</references>
<section title="Design Considerations" toc="default">
<section title="General" toc="default">
<t>
One of the main issues regarding the BUNDLE grouping extensions has been whether,
in SDP Offers and SDP Answers, the same port number value should be inserted in "m="
lines associated with a BUNDLE group, as the purpose of the extension is to negotiate
the usage of a single 5-tuple for media associated with the "m=" lines. Issues
with both approaches, discussed in the Appendix have been raised. The outcome was
to specify a mechanism which uses SDP Offers with both different and identical
port number values.
</t>
<t>
Below are the primary issues that have been considered when defining the "BUNDLE"
grouping extension:
<list style="symbols">
<t>1) Interoperability with existing UAs.</t>
<t>2) Interoperability with intermediary B2BUA- 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 zero.</t>
</list>
</t>
<t>
NOTE: Before this document is published as an RFC, this Appendix might be removed.
</t>
</section>
<section title="UA Interoperability" toc="default">
<t>
Consider the following SDP Offer/Answer exchange, where Alice sends an SDP Offer to Bob:
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 97
a=rtpmap:97 H261/90000
]]></artwork>
</figure>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Answer
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 20000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 20002 RTP/AVP 97
a=rtpmap:97 H261/90000
]]></artwork>
</figure>
<t>
RFC 4961 specifies a way of doing symmetric RTP but that is an a later
invention to RTP and Bob can not assume that Alice supports RFC 4961. This
means that Alice may be sending RTP from a different port than 10000 or
10002 - some implementation simply send the RTP from an ephemeral
port. When Bob's endpoint receives an RTP packet, the only way that Bob
know if it should be passed to the video or audio codec is by looking at
the port it was received on. This lead some SDP implementations to use the
fact that each "m=" line had a different port number to use that port
number as an index to find the correct m line in the SDP. As a result, some
implementations that do support symmetric RTP and ICE still use a SDP data
structure where SDP with "m=" lines with the same port such as:
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 98
a=rtpmap:98 H261/90000
]]></artwork>
</figure>
<t>
will result in the second "m=" line being considered an SDP error
because it has the same port as the first line.
</t>
</section>
<section title="Usage of port number value zero" toc="default">
<t>
In an SDP Offer or SDP Answer, the media associated with an "m=" line can be
disabled/rejected by setting the port number value to zero. This is different
from e.g. using the SDP direction attributes, where RTCP traffic will
continue even if the SDP "inactive" attribute is indicated for the
associated "m=" line.
</t>
<t>
If each "m=" line associated with a BUNDLE group would contain different
port number values, and one of those port would be used for the 5-tuple,
problems would occur if an endpoint wants to disable/reject the "m=" line
associated with that port, by setting the port number value to zero. After that,
no "m=" line would contain the port number value which is used for the 5-tuple.
In addition, it is unclear what would happen to the ICE candidates associated
with the "m=" line, as they are also used for the 5-tuple.
</t>
</section>
<section title="B2BUA And Proxy Interoperability" toc="default">
<t>
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
understand, the B2BUS still generates that SDP attribute in the Offer
for the outgoing call leg. Consider an B2BUA that did not understand
the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way.
Further assume that the B2BUA was configured to tear down any call
where it did not see any RTCP for 5 minutes. In this cases, if the B2BUA
received an Offer like:
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtcp:53020
]]></artwork>
</figure>
<t>
It would be looking for RTCP on port 49172 but would not see any
because the RTCP would be on port 53020 and after five minutes, it would
tear down the call. Similarly, an SBC that did not understand BUNDLE yet
put BUNDLE in it's 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
Offer with capabilities it does not understand is not compliant with the
specifications.
</t>
<section title="Traffic Policing" toc="default">
<t>
Sometimes intermediaries do not act as B2BUA, in the sense that
they don't modify SDP bodies, nor do they terminate SIP dialogs.
Still, however, they may use SDP information (e.g. IP address and
port) in order to control traffic gating functions, and to set
traffic policing rules. There might be rules which will trigger
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
session is already established and ongoing.
</t>
</section>
<section title="Bandwidth Allocation" toc="default">
<t>
Sometimes intermediaries do not act as B2BUA, in the sense that
they don't modify SDP bodies, nor do they terminate SIP dialogs.
Still, however, they may use SDP information (e.g. codecs and
media types) in order to control bandwidth allocation functions.
The bandwidth allocation is done per "m=" line, which means that
it might not be enough if media associated with all "m=" lines
try to use that bandwidth. That may either simply lead to bad
user experience, or to termination of the call.
</t>
</section>
</section>
<section title="Candidate Gathering" toc="default">
<t>
When using ICE, an candidate needs to be gathered for each port. This
takes approximately 20 ms extra for each extra "m=" line due to the NAT
pacing requirements. All of this gather can be overlapped with other
things while the page is loading to minimize the impact. If the client
only wants to generate TURN or STUN ICE candidates for one of the "m="
lines and then use trickle ICE <xref target="I-D.ietf-mmusic-trickle-ice" />
to get the non host ICE candidates for the rest of the "m=" lines, it MAY do
that and will not need any additional gathering time.
</t>
<t>
Some people have suggested a TURN extension to get a bunch of TURN
allocation at once. This would only provide a single STUN result so in
cases where the other end did not support BUNDLE, may cause more use of
the TURN server but would be quick in the cases where both sides
supported BUNDLE and would fall back to a successful call in the other
cases.
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:21:19 |