draft-ietf-mmusic-sdp-bundle-negotiation-03.txt   draft-ietf-mmusic-sdp-bundle-negotiation-04.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track H. Alvestrand Intended status: Standards Track H. Alvestrand
Expires: August 22, 2013 Google Expires: December 16, 2013 Google
C. Jennings C. Jennings
Cisco Cisco
February 18, 2013 June 14, 2013
Multiplexing Negotiation Using Session Description Protocol (SDP) Port Multiplexing Negotiation Using Session Description Protocol (SDP) Port
Numbers Numbers
draft-ietf-mmusic-sdp-bundle-negotiation-03.txt draft-ietf-mmusic-sdp-bundle-negotiation-04.txt
Abstract Abstract
This specification defines a new SDP Grouping Framework extension, This specification defines a new SDP Grouping Framework extension,
"BUNDLE", that can be used with the Session Description Protocol "BUNDLE", that can be used with the Session Description Protocol
(SDP) Offer/Answer mechanism to negotiate the usage of bundled media, (SDP) Offer/Answer mechanism to negotiate the usage of bundled media,
which refers to the usage of a single 5-tuple for media associated which refers to the usage of a single 5-tuple for media associated
with multiple SDP media descriptions ("m=" lines). with multiple SDP media descriptions ("m=" lines).
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 22, 2013. This Internet-Draft will expire on December 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 4 5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 5
6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. SDP Offerer Procedures . . . . . . . . . . . . . . . . . . 5 6.2. Bundled SDP Information . . . . . . . . . . . . . . . . . 5
6.3. SDP Answerer Procedures . . . . . . . . . . . . . . . . . 7 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
6.4. Bundled SDP Information . . . . . . . . . . . . . . . . . 7 6.2.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 6
6.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 6.2.3. rtcp-mux Attribute . . . . . . . . . . . . . . . . . 6
6.4.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . 7 6.2.4. rtcp Attribute . . . . . . . . . . . . . . . . . . . 6
6.4.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . 7 6.2.5. DTLS-SRTP fingerprint Attribute . . . . . . . . . . . 6
7. Single vs Multiple RTP Sessions . . . . . . . . . . . . . . . 8 6.2.6. SDES crypto Attribute . . . . . . . . . . . . . . . . 6
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2.7. Other Attributes (a=) . . . . . . . . . . . . . . . . 6
7.2. Single RTP Session . . . . . . . . . . . . . . . . . . . . 8 6.3. RFC 5888 restrictions . . . . . . . . . . . . . . . . . . 6
8. Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . . 8 6.4. SDP Offerer Procedures . . . . . . . . . . . . . . . . . 6
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.4.1. SDP Offerer Bundle Address Request and Usage . . . . 7
8.2. Candidates . . . . . . . . . . . . . . . . . . . . . . . . 9 6.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 7
8.3. Candidates . . . . . . . . . . . . . . . . . . . . . . . . 9 6.4.3. Adding a media description to a BUNDLE group . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6.4.4. Moving A Media Description Out Of A BUNDLE Group . . 8
10. Example: SDP Offer with different port number values . . . . . 9 6.4.5. Disabling A Media Description In A BUNDLE Group . . . 9
11. Example: SDP Offer with identical port number values . . . . . 11 6.5. SDP Answerer Procedures . . . . . . . . . . . . . . . . . 9
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.5.1. Answerer Bundle Address Selection and Usage . . . . . 9
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6.5.2. Moving A Media Description Out Of A BUNDLE Group . . 10
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.5.3. Rejecting A Media Description In A BUNDLE Group . . . 10
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Single vs Multiple RTP Sessions . . . . . . . . . . . . . . . 11
15.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
15.2. Informative References . . . . . . . . . . . . . . . . . . 14 7.2. Single RTP Session . . . . . . . . . . . . . . . . . . . 11
Appendix A. Design Considerations . . . . . . . . . . . . . . . . 15 8. Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . 11
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 15 8.2. Candidates . . . . . . . . . . . . . . . . . . . . . . . 11
A.3. Usage of port number value zero . . . . . . . . . . . . . 16 8.3. Candidates . . . . . . . . . . . . . . . . . . . . . . . 12
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . . 18 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . . 18 10.1. Example: Bundle Address Selection . . . . . . . . . . . 12
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 18 10.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 10.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 17
10.5. Example: Offerer Disables A Media Description In A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Design Considerations . . . . . . . . . . . . . . . 21
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 22
A.3. Usage of port number value zero . . . . . . . . . . . . . 23
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 24
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 24
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 25
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and 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=" receiving media associated with multiple SDP media descriptions ("m="
lines) has been identified. This would e.g. allow the usage of a lines) has been identified. This would e.g. allow the usage of a
single set of Interactive Connectivity Establishment (ICE) [RFC5245] single set of Interactive Connectivity Establishment (ICE) [RFC5245]
candidates for multiple media descriptions. Normally different media candidates for multiple media descriptions. Normally different media
types (audio, video etc) will be described using different media types (audio, video etc) will be described using different media
descriptions. descriptions.
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension, "BUNDLE", that can be used with the Session Description extension, "BUNDLE", that can be used with the Session Description
Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate the Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate the
usage of bundled media, which refers to the usage of a single 5-tuple usage of bundled media, which refers to the usage of a single 5-tuple
for media associated with multiple SDP media descriptions ("m=" for media associated with multiple SDP media descriptions ("m="
lines). lines).
The SDP Offerer and SDP Answerer [RFC3264] use the "BUNDLE" grouping The Offerer and Answerer [RFC3264] use the BUNDLE mechanism to
extension to indicate which media is associated with a single negotiate a single BUNDLE address to be used for the bundled media
5-tuple. For each media, the associated "m=" line is associated with associated with a BUNDLE group.
a "BUNDLE" group.
For each "BUNDLE" group, the SDP Offerer and SDP Answerer use an The BUNDLE mechanism allows an SDP Offerer and SDP Answerer to assign
identical port number value in each "m=" line associated with the identical addresses to multiple "m=" lines, if those "m=" lines are
"BUNDLE" group. However, until it is known that the SDP Answerer associated with a BUNDLE group. However, until it is known whether
supports the "BUNDLE" grouping extension, when the SDP Offerer both the Offerer and Answerer support the BUNDLE mechanism, unique
generates an SDP Offer, a different port number value is inserted for addresses are assigned to each "m=" line, including those associated
each "m=" line associated with the "BUNDLE" group. The port number with a BUNDLE group.
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.
NOTE: As defined in RFC 4566 [RFC4566], the semantics of multiple NOTE: As defined in RFC 4566 [RFC4566], the semantics of multiple
"m=" lines using the same port number value are undefined, and there "m=" lines using the same port number value are undefined, and there
is no grouping defined by such means. Instead, an explicit grouping is no grouping defined by such means. Instead, an explicit grouping
mechanism needs to be used to express the intended semantics. This mechanism needs to be used to express the intended semantics. This
specification provides such extension. specification provides such extension.
SDP Offers and SDP Answer can contain multiple "BUNDLE" groups. For SDP Offers and SDP Answer can contain multiple BUNDLE groups. For
each "BUNDLE" group, a different port number value MUST be used. each BUNDLE group, a BUNDLE address is negotiated. Multiple BUNDLE
groups cannot share the same bundle address.
When media is transported using the Real-Time Protocol (RTP) The default assumption is that all Real-Time Protocol (RTP) [RFC3550]
[RFC3550], the default assumption of the mechanism is that all media based media flows within a BUNDLE group belongs to the same RTP
associated with a "BUNDLE" group will form a single RTP Session Session [RFC3550]. Future extensions can change that assumption.
[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.
The mechanism is backward compatible. Endpoints that do not support The BUNDLE mechanism is backward compatible. Endpoints that do not
the "BUNDLE" grouping extension are expected to generate SDP Offers support the BUNDLE mechanism are expected to generate SDP Offers and
and SDP Answers without inserting a "BUNDLE" group, and to insert SDP Answers without an SDP group:BUNDLE attribute, and are expected
different port number values in each "m=" line, in the SDP Offers and to assign unique addresses to each "m=" line, according to the
SDP Answers, as defined in RFC 4566 and RFC 3264. procedures in [RFC4566] and [RFC3264]
2. Terminology 2. Terminology
5-tuple: A collection of the following values: source address, source 5-tuple: A collection of the following values: source address, source
port, destination address, destination port and protocol. port, destination address, destination port and protocol.
Bundled media: Two or more RTP streams using a single 5-tuple. The Bundled media: Two or more RTP streams using a single 5-tuple. The
RTCP streams associated with the RTP streams also use a single 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 5-tuple, which might be the same, but can also be different, as the
one used by the RTP streams. one used by the RTP streams.
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.
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.
NOTE: "m=" lines that share a BUNDLE address MUST also share other
parameters related to the media transport plane, e.g. ICE candidate
information.
3. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
4. Applicability Statement 4. Applicability Statement
The mechanism in this specification only applies to the Session The mechanism in this specification only applies to the Session
Description Protocol (SDP) [RFC4566], when used together with the SDP Description Protocol (SDP) [RFC4566], when used together with the SDP
Offer/Answer mechanism [RFC3264]. Offer/Answer mechanism [RFC3264].
5. SDP Grouping Framework BUNDLE Extension Semantics 5. SDP Grouping Framework BUNDLE Extension Semantics
This section defines a new SDP Grouping Framework extension, This section defines a new SDP Grouping Framework extension, BUNDLE.
"BUNDLE".
The "BUNDLE" extension can be indicated using an SDP session-level The BUNDLE extension can be indicated using an SDP session-level
'group' attribute. Each SDP media description ("m=" line) that is 'group' attribute. Each SDP Media Description ("m=" line) that is
grouped together, using an SDP media-level 'mid' attribute, is part grouped together, using SDP media-level mid attributes, belongs to a
of a specific "BUNDLE" group. given BUNDLE group.
6. SDP Offer/Answer Procedures 6. SDP Offer/Answer Procedures
6.1. General 6.1. General
When an endpoint generates an SDP Offer or SDP Answer, which contains This section describes the usage of the SDP Offer/Answer mechanism
a "BUNDLE" group, it MUST insert an SDP session-level 'group' [RFC3264] to negotiate the usage of the BUNDLE mechanism, to
attribute, with a "BUNDLE" value, and assign SDP media-level 'mid' negotiate the BUNDLE address, and to add, remove and reject SDP Media
attribute values for each "m=" line associated the "BUNDLE" group. Descriptions ("m=" lines) [RFC4566] associated with a BUNDLE group.
Until it is known whether the SDP Answerer supports the "BUNDLE" The generic rules and procedures defined in [RFC3264] and [RFC5888]
grouping extension, the SDP Offerer MUST, for each "m=" line apply when the SDP Offer/Answer mechanism is used with the BUNDLE
associated with a "BUNDLE" group: mechanism. For example, if an SDP Offer is rejected, the previously
negotiated SDP parameters and characteristics (including those
associated with BUNDLE groups) apply.
o 1. Insert different port number values. When an endpoint, acting as an Offerer or Answerer [RFC3264],
o 2. Insert identical connection data ("c=" line) value. generates an SDP Offer, or an SDP Answer, the endpoint MUST assign an
o 3. Insert different SDP 'rtcp' attribute value, when used. SDP media-level mid value for each "m=" line in a BUNDLE group. In
o 4. Insert different ICE candidate values, when used. addition, the endpoint MUST assign an SDP session-level group:BUNDLE
o 5. Insert an SDP 'rtpc-mux' attribute. attribute for each BUNDLE group, and place each mid associated with
o 6. Insert identical DTLS-SRTP fingerprint attribute, when used the SDP group:BUNDLE attribute mid list.
o 7. Insert different SDES crypto attribute, when used
Once it is known that both endpoints support the "BUNDLE" grouping 6.2. Bundled SDP Information
extension, the SDP Offerer and SDP Answerer MUST, for each "m=" line
associated with a "BUNDLE" group:
o 1. Insert identical port number values. 6.2.1. General
o 2. Insert identical connection data ("c=" line) value.
o 3. Insert identical SDP 'rtcp' attribute value, when used.
o 4. Insert identical ICE candidate values, when used.
o 5. Insert an SDP 'rtpc-mux' attribute.
o 6. Insert identical DTLS-SRTP fingerprint attribute, when used
o 7. Insert different SDES crypto attribute, when used
Once both endpoints have indicated support of the "BUNDLE" grouping This section describes restrictions associated with the usage of SDP
extension, they can start using the single port for the media parameters and extensions within a BUNDLE group. It also describes,
associated with each "m=" line in the "BUNDLE group". 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.
OPEN ISSUE #1: If the SDP Answerer supports "BUNDLE", do we mandate 6.2.2. Bandwidth (b=)
that "m=" lines must be grouped in the same way in the SDP Answer as
they are grouped in the SDP Offer?
6.2. SDP Offerer Procedures The total proposed bandwidth is the sum of the proposed bandwidth for
each "m=" line associated with a negotiated BUNDLE group.
When the SDP Offerer generates an SDP Offer that contains a "BUNDLE" 6.2.3. rtcp-mux Attribute
group, the SDP Offer MUST be generated according to the procedures in
Section 6.1.
If the associated SDP Answer contains a "BUNDLE" group, and the SDP For each "m=" line in a BUNDLE group, an Offerer and Answerer MUST
Offer contained different port number values in each "m=" line assign an SDP rtcp-mux attribute [RFC5761].
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.
NOTE: The reason for sending the new SDP Offer, which includes an 6.2.4. rtcp Attribute
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.
If the SDP Offer contains different port number values for each "m=" When used, for each RTP media "m=" line in a BUNDLE group, an Offerer
lines associated with the "BUNDLE" group, and if the associated SDP and Answerer MUST assign an SDP rtcp attribute [RFC3605] with an
Answer does not contain a "BUNDLE" group, the SDP Offerer MUST use identical attribute value.
the different port number values that were included in the SDP Offer.
Once it is known that both the SDP Offerer and SDP Answerer support 6.2.5. DTLS-SRTP fingerprint Attribute
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.
NOTE: If needed, the SDP Offerer is allowed to change the port number When DTLS-SRTP is used, for each RTP media "m=" line in a BUNDLE
value in an subsequent SDP Offer, but it still inserts the same group, an Offerer and Answerer MUST assign an SDP DTLS-SRTP
identical port number value in each "m=" line associated with the fingerprint attribute with identical attribute values.
"BUNDLE" group.
When generating an SDP Offer, if the SDP Offerer wants to disable 6.2.6. SDES crypto Attribute
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.
The SDP Offerer MUST NOT insert an identical port number value in When SDES is used, for each RTP media "m=" line in a BUNDLE group, an
multiple "m=" lines, unless the "m=" lines are associated with a Offerer and Answerer MUST assign an SDP crypto attribute, with unique
"BUNDLE" group. attribute values.
OPEN ISSUE #2: If the session has been established without BUNDLE, do 6.2.7. Other Attributes (a=)
we allow BUNDLE to be enabled later during the session?
OPEN ISSUE #3: If the session has been established with BUNDLE, do we There are also special rules for handling many different attributes
allow BUNDLE to be disabled later during the session, meaning that as defined in [I-D.nandakumar-mmusic-sdp-attributes]. It might not
different port number values will be used for media associated with possible to use bundle with some attributes.
each "m=" line?
6.3. SDP Answerer Procedures 6.3. RFC 5888 restrictions
When an SDP Answerer receives an SDP Offer which contains a "BUNDLE" Based on the rules and procedures in [RFC5888], the following
group, and the SDP Answerer accepts the offered "BUNDLE" group, the restrictions also apply to BUNDLE groups in SDP Answers:
SDP Answerer MUST generate an SDP Answer according to the procedures
in Section 6.1.
When generating the SDP Answer, if the SDP Answerer wants to reject o 1) A BUNDLE group must not be added to an SDP Answer, unless the
media associated with an "m=" line in the "BUNDLE" group, it will same BUNDLE group was included in the associated SDP Offer; and
insert a zero port number value in the disabled "m=" line, as defined
in RFC 3264.
The SDP Answerer MUST NOT insert a "BUNDLE" group in an SDP Answer, o 2) An SDP "m=" line must not be added to a BUNDLE group in the SDP
unless the associated SDP Offer contains a "BUNDLE" group. Answer, unless it was in the same BUNDLE group in the associated
SDP Offer.
The SDP Answerer MUST NOT insert an identical port number value in 6.4. SDP Offerer Procedures
multiple "m=" lines, unless the "m=" lines are associated with a 6.4.1. SDP Offerer Bundle Address Request and Usage
"BUNDLE" group.
Until the SDP Answerer receives the new SDP Offer, which contains an An Offerer can assign a BUNDLE address to multiple "m=" lines in a
identical port number value for each "m=" line associated with a BUNDLE group, once the Answerer has selected the BUNDLE address for
"BUNDLE" group, it MUST use the port, and related information (ICE the Offerer. An Offerer MUST NOT assign a BUNDLE address to multiple
candidates, SDES keys etc) associated with the first "m=" line in the "m=" lines until the Answerer has selected the BUNDLE address.
"BUNDLE" group.
6.4. Bundled SDP Information OPEN ISSUE: Should it be allowed to assign a new BUNDLE address to
multiple "m=" lines in a BUNDLE group, before the Answerer has
selected the BUNDLE address?
6.4.1. General In order to negotiate (or, to re-negotiate) the BUNDLE address
associated with a BUNDLE group, the Offerer, in the SDP Offer,
assigns a unique address to each "m=" line in the BUNDLE group. In
addition, the Offerer indicates which unique address it wishes the
Answerer to select as the Offerer's BUNDLE address. The Offerer
places the mid, associated with the unique address requested to be
selected as the BUNDLE address, first in the SDP group:BUNDLE
attribute mid list. The Answerer will then select the BUNDLE address
for the Offerer ([ref-to-be-added]).
This section describes how SDP information, given for each media If the Offerer, in a subsequent SDP Offer, wants to re-negotiate the
description, is calculated into a single value for a "BUNDLE" group. BUNDLE address associated with a BUNDLE group, it MAY assign the
previously negotiated BUNDLE address as a unique address to one of
the "m=" lines in the BUNDLE group.
6.4.2. Bandwidth (b=) If the Offerer assigns the previously selected BUNDLE address to more
than one "m=" line in a BUNDLE group, the first mid in the SDP
group:BUNDLE attribute mid list MUST represent an "m=" line to which
the BUNDLE address is assigned. Hence, in order to re-negotiate the
BUNDLE address, the Offerer needs to assign a unique address to each
"m=" line in the BUNDLE group, as described above.
The total proposed bandwidth is the sum of the proposed bandwidth for An Offerer MUST NOT assign a BUNDLE address to an "m=" line that is
each "m=" line associated with a negotiated BUNDLE group. not associated with a BUNDLE group. An Offerer MUST NOT assign a
BUNDLE address, that has been negotiated for a BUNDLE group, to an
"m=" line that is associated with another BUNDLE group.
6.4.3. Attributes (a=) Section 10.1 shows an example of a Bundle Address Request.
There are also special rules for handling many different attributes 6.4.2. Bundle Address Synchronization (BAS)
as defined in [I-D.nandakumar-mmusic-sdp-attributes]. It might not
possible to use bundle with some attributes. When an Offerer has requested the Answerer to select the Offerer's
BUNDLE address, and the Offerer did not assign the requested BUNDLE
address to each "m=" line in the BUNDLE group of the SDP Offer used
to request the BUNDLE address, when the associated SDP Answer is
received the Offerer MUST send a subsequent SDP Offer. In the
subsequent SDP Offer the Offerer MUST assign the selected BUNDLE
address to each "m=" line in the BUNDLE group. This procedure is
referred to as Bundle Address Synchronization (BAS).
When the Offerer performs a BAS, the Offerer MAY modify SDP
parameters in the same SDP Offer.
NOTE: It is important that the SDP Offer used for the BAS 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 SDP Offer. Removing "m=" lines, or reducing the number of
codecs, in the SDP Offer used for the BAS is considered to have a low
risk of being rejected.
NOTE: The main purpose of the BAS is to make sure that
intermediaries, that might not support the BUNDLE mechanism, have
correct information regarding which IP address and port is going to
be used for the bundled media.
Section 10.1 shows an example of an SDP Offer used to perform a BAS.
6.4.3. Adding a media description to a BUNDLE group
When an Offerer adds an "m=" line to a BUNDLE group, the Offerer MUST
assign either a unique address, or the BUNDLE address associated with
the BUNDLE group, to the added "m=" line. In addition, the Offerer
MUST assign a mid value to the "m=" line, and place the mid in the
SDP group:BUNDLE attribute mid list associated with the BUNDLE group,
in order to group the "m=" line to the BUNDLE group.
NOTE: If the Offerer assigns a unique address to the added "m=" line,
it allows the Answerer to move the "m=" line out of the BUNDLE group
without having to reject the "m=" line ([ref-to-be-added]).
To the previously added "m=" lines in the BUNDLE group, the Offerer
assigns either unique addresses or the BUNDLE address associated with
the BUNDLE group, according to the procedures in Section 6.4.1.
Section 10.3 shows an example of an SDP Offer used to add an "m="
line to a BUNDLE group.
6.4.4. Moving A Media Description Out Of A BUNDLE Group
When an Offerer moves an "m=" line out of a BUNDLE group, the Offerer
MUST assign a unique address to the moved "m=" line. In addition,
the Offerer MUST NOT anymore use a mid value to group the "m=" line
with the BUNDLE group.
To the remaining "m=" lines in the BUNDLE group, the Offerer assigns
either unique addresses or the BUNDLE address associated with the
BUNDLE group, according to the procedures in Section 6.4.1.
Section 10.4 shows an example of an SDP Offer used to move an "m="
line out of a BUNDLE group.
6.4.5. Disabling A Media Description In A BUNDLE Group
When an Offerer disables an "m=" line in a BUNDLE group, the Offerer
MUST assign a zero port value [RFC3264] to the disabled "m=" line.
In addition, the Offerer MUST NOT anymore use a mid value to group
the "m=" line with the BUNDLE group.
To the remaining "m=" lines in the BUNDLE group, the Offerer assigns
either unique addresses or the BUNDLE address associated with the
BUNDLE group, according to the procedures in Section 6.4.1.
Section 10.5 shows an example of an SDP Offer used to move an "m="
line out of a BUNDLE group.
6.5. SDP Answerer Procedures
6.5.1. Answerer Bundle Address Selection and Usage
6.5.1.1. Offerer Bundle Address Selection
If the Offerer, in an SDP Offer, assigned a unique address to each
"m=" line in a BUNDLE group, it means that the Offerer has requested
the Answerer to select a BUNDLE address for the Offerer. The first
mid in the SDP group:BUNDLE attribute mid list of the SDP Offer
represents the unique address which the Offerer requests the Answer
to select as the Offerer's BUNDLE address.
The Answerer SHOULD select the unique address associated with the
first mid to become the Offerer's BUNDLE address, unless the Answerer
in the SDP Answer will move the "m=" line represented by the mid out
of the BUNDLE group, or if there is some other reason why the
Answerer can not select the unique address associated with the mid.
In that case, the Answerer MUST try the next mid in the list.
In the SDP Answer, the Answerer MUST place the mid associated with
the selected BUNDLE address first in the SDP group:BUNDLE attribute
mid list associated with the BUNDLE group.
Section 10.1 shows an example of an Offerer's BUNDLE address
selection.
6.5.1.2. Anwerer Bundle Address Selection
The Answerer MUST select a local BUNDLE address, and in the SDP
Answer assign it to each "m=" line associated with the BUNDLE group.
The Answerer is allowed to change its BUNDLE address in any SDP
Answer.
The Answerer MUST NOT assign a BUNDLE address to an "m=" line that is
not associated with a BUNDLE group. The Answerer MUST NOT assign a
BUNDLE address, associated with a BUNDLE group, to an "m=" line
associated with another BUNDLE group.
Section 10.1 shows an example of an Answerer's local BUNDLE address
selection.
6.5.2. Moving A Media Description Out Of A BUNDLE Group
When an Answerer moves an "m=" line out of a BUNDLE group, the
Answerer MUST assign a unique address to the moved "m=" line. In
addition, the Answerer MUST NOT anymore use a mid value to group the
"m=" line with the BUNDLE group.
To the remaining "m=" lines in the BUNDLE group, the Answerer assigns
the Answerer's BUNDLE address.
An Answerer MUST NOT move an "m=" line out of a BUNDLE group, unless:
o 1) The Offerer assigned a unique address to the "m=" line in the
associated SDP Offer; or
o 2) The Answerer also rejects the "m=" line Section 6.5.3.
6.5.3. Rejecting A Media Description In A BUNDLE Group
When an Answerer rejects an "m=" line in a BUNDLE group, the Answerer
MUST assign a zero port value to the rejected "m=" line. In
addition, the Answerer MUST NOT anymore use a mid value to group the
"m=" line with the BUNDLE group.
To the remaining "m=" lines in the BUNDLE group, the Answerer assigns
the Answerer's BUNDLE address.
7. Single vs Multiple RTP Sessions 7. Single vs Multiple RTP Sessions
7.1. General 7.1. General
When entities negotiate the usage of bundled media, the default By default, all RTP based media flows within a given BUNDLE group
assumption is that all media associated with the bundled media will belong to a single RTP session [RFC3550]. Multiple BUNDLE groups
form a single RTP session. will form multiple RTP Sessions.
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.
It is possible to use multiple "BUNDLE" groups, in case the RTP media The usage of multiple RTP Sessions within a given BUNDLE group, or
within each group will be part of different RTP Sessions. 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.
7.2. Single RTP Session 7.2. Single RTP Session
When a single RTP Session is used, media associated with all "m=" When a single RTP Session is used, media associated with all "m="
lines part of a bundle group share a single SSRC [RFC3550] numbering lines part of a bundle group share a single SSRC [RFC3550] numbering
space. space.
In addition, the following rules and restrictions apply for a single In addition, the following rules and restrictions apply for a single
RTP Session: RTP Session:
o - The dynamic payload type values used in the "m=" lines MUST NOT o - The dynamic payload type values used in the "m=" lines MUST NOT
overlap. overlap.
o - The "proto" value in each "m=" line MUST be identical (e.g.
RTP/AVPF). o - The "proto" value in each "m=" line MUST be identical (e.g. RTP/
AVPF).
o - A given SSRC SHOULD NOT transmit RTP packets using payload types o - A given SSRC SHOULD NOT transmit RTP packets using payload types
that originates from different "m=" lines. that originates from different "m=" lines.
NOTE: The last bullet above is to avoid sending multiple media types NOTE: The last bullet above is to avoid sending multiple media types
from the same SSRC. If transmission of multiple media types are done from the same SSRC. If transmission of multiple media types are done
with time overlap RTP and RTCP fails to function. Even if done in with time overlap RTP and RTCP fails to function. Even if done in
proper sequence this causes RTP Timestamp rate switching issues [ref proper sequence this causes RTP Timestamp rate switching issues [ref
to draft-ietf-avtext-multiple-clock-rates]. to draft-ietf-avtext-multiple-clock-rates].
8. Usage With ICE 8. Usage With ICE
8.1. General 8.1. General
This section describes how to use the "BUNDLE" grouping extension This section describes how to use the BUNDLE grouping extension
together with the Interactive Connectivity Establishment (ICE) together with the Interactive Connectivity Establishment (ICE)
mechanism [RFC5245]. mechanism [RFC5245].
8.2. Candidates 8.2. Candidates
When an ICE-enabled endpoint generates an SDP Offer, which contains a When an ICE-enabled endpoint generates an SDP Offer, which contains a
"BUNDLE" group, the SDP Offerer MUST include ICE candidates for each BUNDLE group, the SDP Offerer MUST include ICE candidates for each
"m=" line associated with a "BUNDLE" group, except for any "m=" line "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 with a zero port number value. If the "m=" lines associated with the
"BUNDLE" group contain different port number values, the SDP Offerer BUNDLE group contain different port number values, the SDP Offerer
MUST also insert different candidate values in each "m=" line MUST also insert different candidate values in each "m=" line
associated with the "BUNDLE" group. If the "m=" lines associated associated with the BUNDLE group. If the "m=" lines associated with
with the "BUNDLE" group contain an identical port number value, the the BUNDLE group contain an identical port number value, the
candidate values MUST also be identical. candidate values MUST also be identical.
When an ICE-enabled endpoint generates and SDP Answer, which contains When an ICE-enabled endpoint generates and SDP Answer, which contains
a "BUNDLE" group, the SDP Answerer MUST include ICE candidates for a BUNDLE group, the Answerer MUST include ICE candidates for each
each "m=" line associated with the "BUNDLE" group, except for any "m=" line associated with the "BUNDLE" group, except for any "m="
"m=" line where the port number value is set to zero. The SDP line where the port number value is set to zero. The Answerer MUST
Answerer MUST insert identical candidate values in each "m=" line insert identical candidate values in each "m=" line associated with
associated with the "BUNDLE" group. the BUNDLE group.
8.3. Candidates 8.3. Candidates
Once it is known that both endpoints support, and accept to use, the Once it is known that both endpoints support, and accept to use, the
"BUNDLE" grouping extension, ICE connectivity checks and keep-alives BUNDLE grouping extension, ICE connectivity checks and keep-alives
only needs to be performed for the whole "BUNDLE" group, instead of only needs to be performed for the whole BUNDLE group, instead of for
for each individual "m=" line associated with the group. each individual "m=" line associated with the group.
9. Security Considerations 9. Security Considerations
This specification does not significantly change the security This specification does not significantly change the security
considerations of SDP which can be found in Section X of TBD. considerations of SDP which can be found in Section X of TBD.
TODO: Think carefully about security analysis of reuse of same SDES 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 key on multiple "m=" lines when the far end does not use BUNDLE and
warn developers of any risks. warn developers of any risks.
10. Example: SDP Offer with different port number values 10. Examples
The example below shows an SDP Offer, where bundled media is offered 10.1. Example: Bundle Address Selection
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.
SDP Offer (Bundled media offered) The example below shows:
o 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.
o 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.
o 3. A subsequent SDP Offer, which is used to perform a Bundle
Address Synchronization (BAS).
SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 host.atlanta.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
SDP Answer (Bundled media accepted) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
s= s=
c=IN IP4 host.biloxi.com c=IN IP4 host.biloxi.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
SDP Answer (Bundled media not accepted) SDP Offer (3)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s= s=
c=IN IP4 host.biloxi.com c=IN IP4 host.atlanta.com
t=0 0 t=0 0
m=audio 20000 RTP/AVP 0 a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
SDP Offer with ICE (Bundled media offered) 10.2. Example: Bundle Mechanism Rejected
The example below shows:
o 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.
o 2. An SDP Answer, in which the Answerer rejects the BUNDLE group,
and assigns unique addresses to each "m=" line.
SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 host.atlanta.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/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 m=video 10002 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=candidate:1 1 UDP 1694498815 host.atlanta.com 10002 typ host
11. Example: SDP Offer with identical port number values SDP Answer (2)
The example below shows an SDP Offer, where bundled media is offered v=0
an identical port number value in the "m=" lines associated with the o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
"BUNDLE" group. The example also shows two SDP Answer alternatives: s=
one where bundled media is accepted, and one where bundled media is c=IN IP4 host.biloxi.com
rejected (or, not even supported) by the SDP Answerer. 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 (Bundled media offered) 10.3. Example: Offerer Adds A Media Description To A BUNDLE Group
The example below shows:
o 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.
o 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.
o 3. A subsequent SDP Offer, which is used to perform a Bundle
Address Synchronization (BAS).
SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 host.atlanta.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar zen
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/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 (Bundled media accepted) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
s= s=
c=IN IP4 host.biloxi.com c=IN IP4 host.biloxi.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar zen
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 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 host.atlanta.com
s=
c=IN IP4 host.atlanta.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
SDP Answer (Bundled media not accepted) 10.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group
The example below shows:
o 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.
o 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.
SDP Offer (1)
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
m=video 50000 RTP/AVP 66
b=AS:1000
a=rtpmap:66 H261/90000
SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
s= s=
c=IN IP4 host.biloxi.com c=IN IP4 host.biloxi.com
t=0 0 t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=video 60000 RTP/AVP 66
b=AS:1000
a=rtpmap:66 H261/90000
SDP Offer with ICE (Bundled media offered) 10.5. Example: Offerer Disables A Media Description In A BUNDLE Group
The example below shows:
o 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.
o 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.
SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s= s=
c=IN IP4 host.atlanta.com c=IN IP4 host.atlanta.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/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 m=video 10000 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host m=video 0 RTP/AVP 66
a=rtpmap:66 H261/90000
12. IANA Considerations SDP Answer (2)
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
m=video 0 RTP/AVP 66
a=rtpmap:66 H261/90000
11. IANA Considerations
This document requests IANA to register the new SDP Grouping semantic This document requests IANA to register the new SDP Grouping semantic
extension called BUNDLE. extension called BUNDLE.
13. Acknowledgements 12. Acknowledgements
The usage of the SDP grouping extension for negotiating bundled media The usage of the SDP grouping extension for negotiating bundled media
is based on a similar alternative proposed by Harald Alvestrand. The is based on a similar alternatives proposed by Harald Alvestrand and
SDP examples are also modified versions from the ones in the 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.
The SDP examples are also modified versions from the ones in the
Alvestrand proposal. Alvestrand proposal.
14. Change Log Thanks to Paul Kyzivat and Martin Thompson for taking the the time to
read the text along the way, and providing useful feedback.
13. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02
o Mechanism modified, to be based on usage of SDP Offers with both o Mechanism modified, to be based on usage of SDP Offers with both
different and identical port number values, depending on whether different and identical port number values, depending on whether
it is known if the remote endpoint supports the extension. it is known if the remote endpoint supports the extension.
o Cullen Jennings added as co-author. o Cullen Jennings added as co-author.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01
o No changes. New version due to expiration. o No changes. New version due to expiration.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00
o No changes. New version due to expiration. o No changes. New version due to expiration.
Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00
o Draft name changed. o Draft name changed.
o Harald Alvestrand added as co-author. o Harald Alvestrand added as co-author.
o "Multiplex" terminology changed to "bundle". o "Multiplex" terminology changed to "bundle".
o Added text about single versus multiple RTP Sessions. o Added text about single versus multiple RTP Sessions.
o Added reference to RFC 3550.
15. References o Added reference to RFC 3550.
15.1. Normative References 14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264, June
June 2002. 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[I-D.nandakumar-mmusic-sdp-attributes] [I-D.nandakumar-mmusic-sdp-attributes]
Nandakumar, S. and C. Jennings, "A Framework for SDP Nandakumar, S. and C. Jennings, "A Framework for SDP
Attributes when Multiplexing", Attributes when Multiplexing", draft-nandakumar-mmusic-
draft-nandakumar-mmusic-sdp-attributes-00 (work in sdp-attributes-00 (work in progress), February 2013.
progress), February 2013.
15.2. Informative References 14.2. Informative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October
2003.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245, April
April 2010. 2010.
Appendix A. Design Considerations Appendix A. Design Considerations
A.1. General A.1. General
One of the main issues regarding the "BUNDLE" grouping extensions has One of the main issues regarding the BUNDLE grouping extensions has
been whether, in SDP Offers and SDP Answers, the same port number been whether, in SDP Offers and SDP Answers, the same port number
value should be inserted in "m=" lines associated with a "BUNDLE" 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 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 single 5-tuple for media associated with the "m=" lines. Issues with
both approaches, discussed in the Appendix have been raised. The both approaches, discussed in the Appendix have been raised. The
outcome was to specify a mechanism which uses SDP Offers with both outcome was to specify a mechanism which uses SDP Offers with both
different and identical port number values. different and identical port number values.
Below are the primary issues that have been considered when defining Below are the primary issues that have been considered when defining
the "BUNDLE" grouping extension: the "BUNDLE" grouping extension:
o 1) Interoperability with existing UAs. o 1) Interoperability with existing UAs.
o 2) Interoperability with intermediary B2BUA- and proxy entities. o 2) Interoperability with intermediary B2BUA- and proxy entities.
o 3) Time to gather, and the number of, ICE candidates. o 3) Time to gather, and the number of, ICE candidates.
o 4) Different error scenarios, and when they occur. o 4) Different error scenarios, and when they occur.
o 5) SDP Offer/Answer impacts, including usage of port number value o 5) SDP Offer/Answer impacts, including usage of port number value
zero. zero.
NOTE: Before this document is published as an RFC, this Appendix NOTE: Before this document is published as an RFC, this
might be removed. Appendix might be removed.
A.2. UA Interoperability A.2. UA Interoperability
Consider the following SDP Offer/Answer exchange, where Alice sends Consider the following SDP Offer/Answer exchange, where Alice sends
an SDP Offer to Bob: an SDP Offer to Bob:
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
skipping to change at page 17, line 4 skipping to change at page 23, line 42
m=video 10000 RTP/AVP 98 m=video 10000 RTP/AVP 98
a=rtpmap:98 H261/90000 a=rtpmap:98 H261/90000
will result in the second "m=" line being considered an SDP error will result in the second "m=" line being considered an SDP error
because it has the same port as the first line. because it has the same port as the first line.
A.3. Usage of port number value zero A.3. Usage of port number value zero
In an SDP Offer or SDP Answer, the media associated with an "m=" line 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. can be disabled/rejected by setting the port number value to zero.
This is different from e.g. using the SDP direction attributes, where This is different from e.g. using the SDP direction attributes, where
RTCP traffic will continue even if the SDP "inactive" attribute is RTCP traffic will continue even if the SDP "inactive" attribute is
indicated for the associated "m=" line. indicated for the associated "m=" line.
If each "m=" line associated with a "BUNDLE" group would contain If each "m=" line associated with a BUNDLE group would contain
different port number values, and one of those port would be used for 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/ the 5-tuple, problems would occur if an endpoint wants to disable/
reject the "m=" line associated with that port, by setting the port reject the "m=" line associated with that port, by setting the port
number value to zero. After that, no "m=" line would contain the 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 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 unclear what would happen to the ICE candidates associated with the
"m=" line, as they are also used for the 5-tuple. "m=" line, as they are also used for the 5-tuple.
A.4. B2BUA And Proxy Interoperability A.4. B2BUA And Proxy Interoperability
skipping to change at page 18, line 9 skipping to change at page 24, line 47
would tear down the call. Similarly, an SBC that did not understand 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 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 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 that generated an Offer with capabilities it does not understand is
not compliant with the specifications. not compliant with the specifications.
A.4.1. Traffic Policing A.4.1. Traffic Policing
Sometimes intermediaries do not act as B2BUA, in the sense that they Sometimes intermediaries do not act as B2BUA, in the sense that they
don't modify SDP bodies, nor do they terminate SIP dialogs. Still, 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 however, they may use SDP information (e.g. IP address and port) in
order to control traffic gating functions, and to set traffic order to control traffic gating functions, and to set traffic
policing rules. There might be rules which will trigger a session to 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 be terminated in case media is not sent or received on the ports
retrieved from the SDP. This typically occurs once the session is retrieved from the SDP. This typically occurs once the session is
already established and ongoing. already established and ongoing.
A.4.2. Bandwidth Allocation A.4.2. Bandwidth Allocation
Sometimes intermediaries do not act as B2BUA, in the sense that they Sometimes intermediaries do not act as B2BUA, in the sense that they
don't modify SDP bodies, nor do they terminate SIP dialogs. Still, don't modify SDP bodies, nor do they terminate SIP dialogs. Still,
 End of changes. 119 change blocks. 
266 lines changed or deleted 597 lines changed or added

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