One document matched: draft-ietf-mmusic-sdp-bundle-negotiation-03.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-03.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>
<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 SDP Offerer and SDP Answerer <xref format="default" pageno="false" target="RFC3264"/> use
the "BUNDLE" grouping extension to indicate which media is associated with a single 5-tuple. For
each media, the associated "m=" line is associated with a "BUNDLE" group.
</t>
<t>
For each "BUNDLE" group, the SDP Offerer and SDP Answerer use an identical port number value
in each "m=" line associated with the "BUNDLE" group. However, until it is known that the
SDP Answerer supports the "BUNDLE" grouping extension, when the SDP Offerer generates an
SDP Offer, a different port number value is inserted for each "m=" line associated with the
"BUNDLE" group. The port number value associated with the first "m=" line associated with
the "BUNDLE" group represents the port value number offered to be used in the single 5-tuple.
</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 different port number value MUST be used.
</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. Endpoints that do not support the "BUNDLE" grouping
extension are expected to generate SDP Offers and SDP Answers without inserting a "BUNDLE"
group, and to insert different port number values in each "m=" line, in the SDP Offers and
SDP Answers, as defined in RFC 4566 and RFC 3264.
</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>
</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 endpoint generates an SDP Offer or SDP Answer, which contains a "BUNDLE"
group, it MUST insert an SDP session-level 'group' attribute, with a "BUNDLE" value,
and assign SDP media-level 'mid' attribute values for each "m=" line associated the
"BUNDLE" group.
</t>
<t>
Until it is known whether the SDP Answerer supports the "BUNDLE" grouping extension,
the SDP Offerer MUST, for each "m=" line associated with a "BUNDLE" group:
</t>
<t>
<list style="symbols">
<t>1. Insert different port number values.</t>
<t>2. Insert identical connection data ("c=" line) value.</t>
<t>3. Insert different SDP 'rtcp' attribute value, when used.</t>
<t>4. Insert different ICE candidate values, when used.</t>
<t>5. Insert an SDP 'rtpc-mux' attribute.</t>
<t>6. Insert identical DTLS-SRTP fingerprint attribute, when used</t>
<t>7. Insert different SDES crypto attribute, when used</t>
</list>
</t>
<t>
Once it is known that both endpoints support the "BUNDLE" grouping extension,
the SDP Offerer and SDP Answerer MUST, for each "m=" line associated with
a "BUNDLE" group:
</t>
<t>
<list style="symbols">
<t>1. Insert identical port number values.</t>
<t>2. Insert identical connection data ("c=" line) value.</t>
<t>3. Insert identical SDP 'rtcp' attribute value, when used.</t>
<t>4. Insert identical ICE candidate values, when used.</t>
<t>5. Insert an SDP 'rtpc-mux' attribute.</t>
<t>6. Insert identical DTLS-SRTP fingerprint attribute, when used</t>
<t>7. Insert different SDES crypto attribute, when used</t>
</list>
</t>
<t>
Once both endpoints have indicated support of the "BUNDLE" grouping extension,
they can start using the single port for the media associated with each "m=" line
in the "BUNDLE group".
</t>
<t>
OPEN ISSUE #1: If the SDP Answerer supports "BUNDLE", do we mandate that
"m=" lines must be grouped in the same way in the SDP Answer as they
are grouped in the SDP Offer?
</t>
</section>
<section title="SDP Offerer Procedures" toc="default">
<t>
When the SDP Offerer generates an SDP Offer that contains a "BUNDLE" group, the SDP
Offer MUST be generated according to the procedures in <xref format="default"
pageno="false" target="sec-oa-gen"/>.
</t>
<t>
If the associated SDP Answer contains a "BUNDLE" group, and the SDP Offer contained
different port number values in each "m=" line associated with the "BUNDLE" group,
the SDP Offerer MUST generate a new SDP Offer, and insert an identical port number
value for each "m=" line associated with the "BUNDLE" group. Unless ICE is used, the
SDP Offerer MUST generate the new SDP Offer immediately when it has received the SDP
Answer indicating that the SDP Answerer supports the "BUNDLE" grouping extension. If
ICE is used, the SDP Offer can wait until the SDP Offer indicating that ICE is
finished is sent, as defined in RFC 5245.
</t>
<t>
NOTE: The reason for sending the new SDP Offer, which includes an identical port number
value in each "m=" line associated with the "BUNDLE" group, is to ensure that
intermediary entities that look at SDP information e.g. for different type of policing
functions, have the correct information regarding which ports will be used for media.
</t>
<t>
If the SDP Offer contains different port number values for each "m=" lines associated
with the "BUNDLE" group, and if the associated SDP Answer does not contain a
"BUNDLE" group, the SDP Offerer MUST use the different port number values that were
included in the SDP Offer.
</t>
<t>
Once it is known that both the SDP Offerer and SDP Answerer support the "BUNDLE"
grouping extension, in each subsequent SDP Offer towards the SDP Answerer, the SDP Offer
MUST insert an identical port number value in each "m=" line associated with the "BUNDLE"
group.
</t>
<t>
NOTE: If needed, the SDP Offerer is allowed to change the port number value in an
subsequent SDP Offer, but it still inserts the same identical port number value in
each "m=" line associated with the "BUNDLE" group.
</t>
<t>
When generating an SDP Offer, if the SDP Offerer wants to disable media associated with an
"m=" line in a "BUNDLE" group, it will insert a zero port number value in the disabled "m="
line, as defined in RFC 3264. However, if the "m=" lines associated with the "BUNDLE" group
contain different port number values (i.e. the SDP Offer is generated until it is known
whether the SDP Answerer supports the "BUNDLE" grouping extension) the SDP Offerer MUST NOT set
the port number value of the first "m=" line associated with the "BUNDLE" group to zero.
</t>
<t>
The SDP Offerer MUST NOT insert an identical port number value in multiple "m=" lines, unless
the "m=" lines are associated with a "BUNDLE" group.
</t>
<t>
OPEN ISSUE #2: If the session has been established without BUNDLE, do we allow BUNDLE to be
enabled later during the session?
</t>
<t>
OPEN ISSUE #3: If the session has been established with BUNDLE, do we allow BUNDLE to be disabled
later during the session, meaning that different port number values will be used for media
associated with each "m=" line?
</t>
</section>
<section title="SDP Answerer Procedures" toc="default">
<t>
When an SDP Answerer receives an SDP Offer which contains a "BUNDLE" group, and the SDP Answerer
accepts the offered "BUNDLE" group, the SDP Answerer MUST generate an SDP Answer according to
the procedures in <xref format="default" pageno="false" target="sec-oa-gen"/>.
</t>
<t>
When generating the SDP Answer, if the SDP Answerer wants to reject media associated with an
"m=" line in the "BUNDLE" group, it will insert a zero port number value in the disabled "m="
line, as defined in RFC 3264.
</t>
<t>
The SDP Answerer MUST NOT insert a "BUNDLE" group in an SDP Answer, unless the associated SDP Offer
contains a "BUNDLE" group.
</t>
<t>
The SDP Answerer MUST NOT insert an identical port number value in multiple "m=" lines, unless
the "m=" lines are associated with a "BUNDLE" group.
</t>
<t>
Until the SDP Answerer receives the new SDP Offer, which contains an identical port number value
for each "m=" line associated with a "BUNDLE" group, it MUST use the port, and related information
(ICE candidates, SDES keys etc) associated with the first "m=" line in the "BUNDLE" group.
</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 title="Attributes (a=)" toc="default">
<t>
There are also special rules for handling many different attributes as defined
in <xref target="I-D.nandakumar-mmusic-sdp-attributes" />. It might not possible
to use bundle with some attributes.
</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>
<t>
It is possible to use multiple "BUNDLE" groups, in case the RTP media within
each group will be part of different RTP Sessions.
</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 extension 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 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 SDP 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 SDP Answerer
MUST insert identical candidate values in each "m=" line associated with the "BUNDLE" group.
</t>
</section>
<section anchor="sec-ice-con-checks" title="Candidates" 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 anchor="sec-security" title="Security Considerations" 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 anchor="sec-example-alt1" title="Example: SDP Offer with different port number values" toc="default">
<t>
The example below shows an SDP Offer, where bundled media is offered using different
port number values in the "m=" lines associated with the "BUNDLE" group. 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 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
]]></artwork>
</figure>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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
]]></artwork>
</figure>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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
]]></artwork>
</figure>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
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 10002 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 10002 typ host
]]></artwork>
</figure>
</section>
<section anchor="sec-example-alt2" title="Example: SDP Offer with identical port number values" toc="default">
<t>
The example below shows an SDP Offer, where bundled media is offered an identical
port number value in the "m=" lines associated with the "BUNDLE" group. 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 extension for negotiating bundled media 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>
</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-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.5888"?>
<reference anchor="I-D.nandakumar-mmusic-sdp-attributes">
<front>
<title abbrev="SDP Attribute Multiplexing">A Framework for SDP Attributes
when Multiplexing</title>
<author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
<organization>Cisco</organization>
<address>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
</address>
</author>
<date day="13" month="February" year="2013" />
</front>
<seriesInfo name="Internet-Draft" value="draft-nandakumar-mmusic-sdp-attributes-00" />
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.5245"?>
</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 host.atlanta.com
s=
c=IN IP4 host.atlanta.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 host.biloxi.com
s=
c=IN IP4 host.biloxi.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 host.atlanta.com
s=
c=IN IP4 host.atlanta.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 host.atlanta.com
s=
c=IN IP4 host.atlanta.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 [TODO REF] 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 13:22:57 |