One document matched: draft-ietf-mmusic-sdp-bundle-negotiation-00.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="trust200811" category="std" docName="draft-ietf-mmusic-sdp-bundle-negotiation-00.txt" obsoletes="" extends="" 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>
<date year="2012" />
<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 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 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>
When an endpoint generates an SDP Offer or SDP Answer <xref format="default" pageno="false"
target="RFC3264"/>, which includes a "BUNDLE" group, each "m=" line associated with the
group will share a single port number value.
</t>
<t>
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>
When media is transported using the Real-Time Protocol (RTP) <xref format="default"
pageno="false" target="RFC3550"/>, the default assumption of the mechanism is that all
media associated with a "BUNDLE" group will form a single RTP Session <xref format="default"
pageno="false" target="RFC3550"/>. However, future specifications can extend the mechanism,
in order to negotiate RTP Session multiplexing, i.e. "BUNDLE" groups where media associated
with a group form multiple RTP Sessions.
</t>
<t>
The mechanism is backward compatible. Entities that do not support the "BUNDLE" grouping
extension, or do not want to enable the mechanism for a given session, are expected to
generate a "normal" SDP Answer, using different port number values for each "m=" line, to
the SDP Offer. The SDP Offerer <xref format="default" pageno="false" target="RFC3264"/>
will still use a single port number value for each media, but as the SDP Answerer
<xref format="default" pageno="false" target="RFC3264"/> will use separate ports a single
5-tuple will not be used for media associated with multiple "m=" lines between the endpoints.
</t>
</section>
<section title="Terminology" 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 RFC 2119 <xref target="RFC2119" pageno="false"
format="default"/>.
</t>
<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>
</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 an SDP media-level 'mid' attribute, is part of a specific "BUNDLE"
group.
</t>
</section>
<section title="SDP Offer/Answer Procedures" toc="default">
<section anchor="sec-oa-gen" title="General" toc="default">
<t>
When an SDP Offerer or SDP Answerer generates an SDP Offer or SDP Answer,
that describes bundled media, it MUST insert an SDP session-level 'group'
attribute, with a "BUNDLE" value, and assign SDP media-level 'mid' attribute
values to each "m=" line associated with the "BUNDLE" group.
</t>
<t>
In addition, the entity that generates the SDP Offer or SDP Answer MUST, for
each "m=" line that is part of the "BUNDLE" group:
</t>
<t>
<list style="symbols">
<t>1. Use the same port number value.</t>
<t>2. Use the same connection data ("c=" line) value.</t>
<t>3. Use the same SDP 'rtcp' attribute value, when used.</t>
<t>4. Use the same ICE candidate values, when used.</t>
<t>5. Insert an SDP 'rtpc-mux' attribute.</t>
</list>
</t>
<t>
NOTE: If an entity wants to disable specific media ("m=" line)
associated with a "BUNDLE" group, it will use a zero port number value for
the "m=" line associated with the media.
</t>
</section>
<section title="SDP Offerer Procedures" toc="default">
<t>
When an SDP Offerer creates an SDP Offer, that offers bundled media, it MUST
create the SDP Offer according to the procedures in <xref format="default"
pageno="false" target="sec-oa-gen"/>.
</t>
<t>
If the associated SDP Answer contains an SDP session-level 'group' attribute,
with a "BUNDLE" value, and the SDP Answer is created according to the proceudres
in <xref format="default" pageno="false" target="sec-oa-gen"/> (the same
port number value is used for each "m=" line associated with the "BUNDLE" group, etc),
the SDP Offerer can start using the same 5-tuple for sending and receiving media,
associated with the group, between the entities.
</t>
<t>
If the SDP Answer does not include a session-level SDP 'group' attribute, with a
"BUNDLE" value, the SDP Offerer cannot use the same 5-tuple for media associated
with multiple "m=" lines.
</t>
<t>
If the SDP Answererer indicates that it will not use bundled media, the SDP Offerer
will still use the single port number value for each "m= line" associated with the
offered "BUNDLE" group, and it will normally be able to separate each individual media.
The default mechanism for separating media received on a single IP address and port
doing this is by using a 5-tuple based mapping for each individual media. If the SDP
Offerer is aware of the Synchronization Source (SSRC) <xref format="default" pageno="false"
target="RFC3550"/> values that the SDP Answerer will use in the media it sends, and
the SSRC values will be unique for each media, the SDP Offerer can separate media based
on the SSRC values.
</t>
<t>
NOTE: Assuming symmetric media is used, the SDP Offerer can use the port information
from the SDP Answer in order to create the 5-tuple mapping for each media.
</t>
<t>
If the SDP Offerer is not able to separate multiple media received on a single
port, it MUST send a new SDP Offer, without offering bundled media, where a separate
port number value is provide for each "m=" line of the SDP Offer.
</t>
<t>
If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has reasons to
believe that the rejection is due to the usage of a single port number value for multiple
"m=" lines, the SDP Offerer SHOULD send a new SDP Offer, without a "BUNDLE" group,
where a separate port number value is provide for each "m=" line of the SDP offer.
</t>
</section>
<section title="SDP Answerer Procedures" toc="default">
<t>
When an SDP Answerer receives an SDP Offer, which offers bundled media, and the
SDP Answerer accepts the offered bundle group, the SDP Answerer MUST create an
SDP Answer according to the procedures in <xref format="default" pageno="false"
target="sec-oa-gen"/>.
</t>
<t>
If the SDP Answerer does not accept the "BUNDLE" group in the SDP Offer, it MUST NOT
include a session-evel 'group' attribute, with a "BUNDLE" value, in
the associated SDP Answer. In addition, the SDP Answerer MUST provide separate
port number values for each "m=" line of the SDP Answer.
</t>
</section>
<section title="Bundled SDP Information" toc="default">
<section title="General" toc="default">
<t>
This section describes how SDP information, given for each media description,
is calculated into a single value for a "BUNDLE" group.
</t>
</section>
<section title="Bandwidth (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>
</section>
<section anchor="sec-rtp" title="Single vs Multiple RTP Sessions" toc="default">
<section title="General" toc="default">
<t>
When entities negotiate the usage of bundled media, the default assumption
is that all media associated with the bundled media will form a single RTP
session.
</t>
<t>
The usage of multiple RTP Sessions within a "BUNDLE" group is outside the scope
of this specification. Other specification needs to extend the mechanism in
order to allow negotiation of such bundle groups.
</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 anchor="sec-ice" title="Usage With ICE" toc="default">
<section anchor="sec-ice-gen" title="General" toc="default">
<t>
This section describes how to use the "BUNDLE" grouping mechanism together
with the Interactive Connectivity Establishment (ICE) mechanism <xref
format="default" pageno="false" target="RFC5245"/>.
</t>
</section>
<section anchor="sec-ice-can" title="Candidates" toc="default">
<t>
When an ICE-enabled SDP Offerer sends an SDP offer, it MUST include ICE candidates
for each "m=" line associated with a "BUNDLE" group. The candidate values MUST be
identical for each "m=" line associated with the group. This rule applies
also to subsequent SDP Offers, when the usage of bundled media has already been
negotiated.
</t>
<t>
When an ICE-enabled SDP Answerer receives an SDP Offer, offering a "BUNDLE" group and
ICE, if the SDP Answerer enables ICE, MUST include ICE candidates for each "m=" line of
the SDP Answer. This also applies for "m=" lines that are part of a "BUNDLE" group, in
which case the candidate values MUST be identical for each "m=" line associated with
the group. This rule applies also to subsequent SDP Answers, when the usage
of bundled media has already been negotiated.
</t>
<t>
Once the usage of bundled media has been negotiated, 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 anchor="sec-security" title="Security Considerations" toc="default">
<t>
TBA
</t>
</section>
<section anchor="sec-example" title="Example" toc="default">
<t>
The example below shows an SDP Offer, where bundled media is offered. The example also
shows two SDP Answer alternatives: one where bundled media is accepted, and one where
bundled media is rejected (or, not even supported) by the SDP Answerer.
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer (Bundled media offered)
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s=
c=IN IP4 host.atlanta.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
SDP Answer (Bundled media accepted)
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
s=
c=IN IP4 host.biloxi.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 Answer (Bundled media not accepted)
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
s=
c=IN IP4 host.biloxi.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
SDP Offer with ICE (Bundled media offered)
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s=
c=IN IP4 host.atlanta.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
a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
]]></artwork>
</figure>
</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 mechanism is based on a similar alternative
proposed by Harald Alvestrand. The SDP examples are also modified versions
from the ones in the Alvestrand proposal.
</t>
<t>
Thanks to the nice flight crew on AY 021 for providing good sparkling
wine, and a nice working athmosphere, for working on this draft.
</t>
</section>
<section title="Change Log">
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</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.5888"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.5245"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:24:41 |