MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson
Intended status: Standards Track H. Alvestrand
Expires: April 17, 2014 Google
C. Jennings
Cisco
October 14, 2013
Multiplexing Negotiation Using Session Description Protocol (SDP) Port
Numbers
draft-ietf-mmusic-sdp-bundle-negotiation-05.txt
Abstract
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).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 17, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Holmberg, et al. Expires April 17, 2014 [Page 1]
Internet-Draft Bundled media October 2013
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 5
6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. Bundled SDP Information . . . . . . . . . . . . . . . . . 5
6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
6.2.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 6
6.2.3. rtcp-mux Attribute . . . . . . . . . . . . . . . . . 6
6.2.4. rtcp Attribute . . . . . . . . . . . . . . . . . . . 6
6.2.5. DTLS-SRTP fingerprint Attribute . . . . . . . . . . . 6
6.2.6. SDES crypto Attribute . . . . . . . . . . . . . . . . 6
6.2.7. Other Attributes (a=) . . . . . . . . . . . . . . . . 6
6.3. RFC 5888 restrictions . . . . . . . . . . . . . . . . . . 6
6.4. SDP Offerer Procedures . . . . . . . . . . . . . . . . . 7
6.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
6.4.2. Request BUNDLE address selection . . . . . . . . . . 8
6.4.3. Bundle Address Synchronization (BAS) . . . . . . . . 8
6.4.4. Adding a media description to a BUNDLE group . . . . 8
6.4.5. Moving A Media Description Out Of A BUNDLE Group . . 9
6.4.6. Disabling A Media Description In A BUNDLE Group . . . 9
6.5. SDP Answerer Procedures . . . . . . . . . . . . . . . . . 9
6.5.1. Offerer Bundle Address Selection . . . . . . . . . . 10
6.5.2. Anwerer Bundle Address Selection . . . . . . . . . . 10
6.5.3. Moving A Media Description Out Of A BUNDLE Group . . 10
6.5.4. Rejecting A Media Description In A BUNDLE Group . . . 11
7. Single vs Multiple RTP Sessions . . . . . . . . . . . . . . . 11
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Single RTP Session . . . . . . . . . . . . . . . . . . . 11
8. Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Candidates . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Candidates . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Example: Bundle Address Selection . . . . . . . . . . . 13
10.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 14
10.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 15
Holmberg, et al. Expires April 17, 2014 [Page 2]
Internet-Draft Bundled media October 2013
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 . . . . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Design Considerations . . . . . . . . . . . . . . . 22
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 23
A.3. Usage of port number value zero . . . . . . . . . . . . . 24
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 25
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 25
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 25
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
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) [RFC5245]
candidates for multiple media descriptions. Normally different media
types (audio, video etc) will be described using different media
descriptions.
This specification defines a new SDP Grouping Framework [RFC5888]
extension, "BUNDLE", that can be used with the Session Description
Protocol (SDP) Offer/Answer mechanism [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).
The Offerer and Answerer [RFC3264] use the BUNDLE mechanism to
negotiate a single BUNDLE address to be used for the bundled media
associated with a BUNDLE group.
The BUNDLE mechanism allows an SDP Offerer and SDP Answerer to assign
identical addresses to multiple "m=" lines, if those "m=" lines are
associated with a BUNDLE group. However, until it is known whether
both the Offerer and Answerer support the BUNDLE mechanism, unique
addresses are assigned to each "m=" line, including those associated
with a BUNDLE group.
Holmberg, et al. Expires April 17, 2014 [Page 3]
Internet-Draft Bundled media October 2013
NOTE: As defined in RFC 4566 [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.
SDP Offers and SDP Answer can contain multiple BUNDLE groups. For
each BUNDLE group, a BUNDLE address is negotiated. Multiple BUNDLE
groups cannot share the same bundle address.
The default assumption is that all Real-Time Protocol (RTP) [RFC3550]
based media flows within a BUNDLE group belongs to the same RTP
Session [RFC3550]. Future extensions can change that assumption.
The BUNDLE mechanism is backward compatible. Endpoints that do not
support the BUNDLE mechanism are expected to generate SDP Offers and
SDP Answers without an SDP group:BUNDLE attribute, and are expected
to assign unique addresses to each "m=" line, according to the
procedures in [RFC4566] and [RFC3264]
2. Terminology
5-tuple: A collection of the following values: source address, source
port, destination address, destination port and protocol.
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.
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.
Holmberg, et al. Expires April 17, 2014 [Page 4]
Internet-Draft Bundled media October 2013
3. Conventions
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
[RFC2119].
4. Applicability Statement
The mechanism in this specification only applies to the Session
Description Protocol (SDP) [RFC4566], when used together with the SDP
Offer/Answer mechanism [RFC3264].
5. SDP Grouping Framework BUNDLE Extension Semantics
This section defines a new SDP Grouping Framework extension, BUNDLE.
The BUNDLE extension can be indicated using an SDP session-level
'group' attribute. Each SDP Media Description ("m=" line) that is
grouped together, using SDP media-level mid attributes, belongs to a
given BUNDLE group.
6. SDP Offer/Answer Procedures
6.1. General
This section describes the usage of the SDP Offer/Answer mechanism
[RFC3264] to negotiate the usage of the BUNDLE mechanism, to
negotiate the BUNDLE address, and to add, remove and reject SDP Media
Descriptions ("m=" lines) [RFC4566] associated with a BUNDLE group.
The generic rules and procedures defined in [RFC3264] and [RFC5888]
apply when the SDP Offer/Answer mechanism is used with the BUNDLE
mechanism. For example, if an SDP Offer is rejected, the previously
negotiated SDP parameters and characteristics (including those
associated with BUNDLE groups) apply.
When an endpoint, acting as an Offerer or Answerer [RFC3264],
generates an SDP Offer, or an SDP Answer, the endpoint MUST assign an
SDP media-level mid value for each "m=" line in a BUNDLE group. In
addition, the endpoint MUST assign an SDP session-level group:BUNDLE
attribute for each BUNDLE group, and place each mid associated with
the SDP group:BUNDLE attribute mid list.
6.2. Bundled SDP Information
6.2.1. General
Holmberg, et al. Expires April 17, 2014 [Page 5]
Internet-Draft Bundled media October 2013
This section describes restrictions associated with the usage of SDP
parameters and extensions within a BUNDLE group. It also describes,
when parameter and attribute values have been assigned to each "m="
line in the BUNDLE group, how to calculate a value for the whole
BUNDLE group.
6.2.2. Bandwidth (b=)
The total proposed bandwidth is the sum of the proposed bandwidth for
each "m=" line associated with a negotiated BUNDLE group.
6.2.3. rtcp-mux Attribute
For each "m=" line in a BUNDLE group, an Offerer and Answerer MUST
assign an SDP rtcp-mux attribute [RFC5761].
6.2.4. rtcp Attribute
When used, for each RTP media "m=" line in a BUNDLE group, an Offerer
and Answerer MUST assign an SDP rtcp attribute [RFC3605] with an
identical attribute value.
6.2.5. DTLS-SRTP fingerprint Attribute
When DTLS-SRTP is used, for each RTP media "m=" line in a BUNDLE
group, an Offerer and Answerer MUST assign an SDP DTLS-SRTP
fingerprint attribute with identical attribute values.
6.2.6. SDES crypto Attribute
When SDES is used, for each RTP media "m=" line in a BUNDLE group, an
Offerer and Answerer MUST assign an SDP crypto attribute, with unique
attribute values.
6.2.7. Other Attributes (a=)
There are also special rules for handling many different attributes
as defined in [I-D.nandakumar-mmusic-sdp-mux-attributes]. It might
not possible to use bundle with some attributes.
6.3. RFC 5888 restrictions
Based on the rules and procedures in [RFC5888], the following
restrictions also apply to BUNDLE groups in SDP Answers:
o 1) A BUNDLE group must not be added to an SDP Answer, unless the
same BUNDLE group was included in the associated SDP Offer; and
Holmberg, et al. Expires April 17, 2014 [Page 6]
Internet-Draft Bundled media October 2013
o 2) An SDP "m=" line must not be added to a BUNDLE group in the SDP
Answer, unless it was in the same BUNDLE group in the associated
SDP Offer.
6.4. SDP Offerer Procedures
6.4.1. General
When an Offerer generates an Offer, it assigns an address to each
"m=" line, according to the procedures in [RFC3264]. To each "m="
line within a BUNDLE group the Offerer assigns either an address that
is unique to that "m=" line, or a shared address that is also
assigned to other "m=" lines within the BUNDLE group. Such shared
address can be, but does not have to be, a previously selected BUNDLE
address Section 6.5.1.
OPEN ISSUE (Q6): There is a discussion on whether assigning a shared
address to multiple "m=" lines shall be allowed until the Answerer
has indicated support of BUNDLE.
o (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12245.html)
The Offerer MUST NOT assign an address (unique or shared), that it
has assigned to an "m=" line within a BUNDLE group, to an "m=" line
outside the BUNDLE group.
The Offerer MUST, for a BUNDLE group, on the SDP session level
[RFC4566], insert an SDP group:BUNDLE attribute associated with the
BUNDLE group. The Offerer MUST assign an SDP 'mid' attribute
[RFC5888] to each "m=" line within the BUNDLE group, and place the
mid value in the group:BUNDLE attribute mid list.
The Offerer MAY assign an SDP 'bundle-only' attribute [ref-to-be-
added] to one or more "m=" lines within a BUNDLE group.
OPEN ISSUE (Q8): It still needs to be decided whether a zero port
value can be assigned to a 'bundle-only' "m=" line.
o (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12075.html)
o (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12226.html)
o (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12339.html)
Holmberg, et al. Expires April 17, 2014 [Page 7]
Internet-Draft Bundled media October 2013
6.4.2. Request BUNDLE address selection
When an Offerer generates an Offer, it MUST indicate which address
(unique or shared) within a BUNDLE group it wishes the Answer to
select as the Offerer's BUNDLE address for the BUNDLE group
Section 6.5.1. The Offerer MUST do this even if the Answerer has, in
a previous Answer within the dialog, already selected the Offerer's
BUNDLE address.
In order to request an address (unique or shared) to be selected as
the Offerer's BUNDLE address for a BUNDLE group, the Offerer places
the mid value, associated with the "m=" line representing the
requested address, first in the SDP group:BUNDLE attribute mid list
associated with the BUNDLE group.
Section 10.1 shows an example of a Bundle Address Request.
6.4.3. Bundle Address Synchronization (BAS)
When an Offerer receives an Answer, in which an offered BUNDLE group
is accepted, if the Offerer in the associated Offer assigned an
address (unique or shared), that does not represent the BUNDLE
address selected for the Offerer, to an "m=" line within the BUNDLE
group, the Offerer MUST send a subsequent Offer, in which it assigns
the BUNDLE address selected for the Offerer to each "m=" line within
the BUNDLE group. This procedure is referred to as Bundle Address
Synchronization (BAS), and the Offer is referred to as a BAS Offer.
The Offerer MAY modify any SDP parameter in a BAS Offer.
NOTE: It is important that the BAS Offer gets accepted by the
Answerer, so the Offerer needs to consider the necessity to modify
SDP parameters that could get the Answerer to reject the BAS Offer.
Removing "m=" lines, or reducing the number of codecs, in the BAS
Offer used for the is considered to have a low risk of being
rejected.
NOTE: The main purpose of the BAS Offer is to make sure that
intermediaries, that might not support the BUNDLE mechanism, have
correct information regarding which address is going to be used for
the bundled media.
Section 10.1 shows an example of an BAS Offer.
6.4.4. Adding a media description to a BUNDLE group
When an Offerer generates an Offer, in which it adds an "m=" line to
a BUNDLE group, the Offerer assigns an address (unique or shared) to
Holmberg, et al. Expires April 17, 2014 [Page 8]
Internet-Draft Bundled media October 2013
the "m=" line, assigns an SDP 'mid' attribute to the "m=" line, and
places the mid value in the group:BUNDLE attribute mid list
associated with the BUNDLE group, according to the procedures in
Section 6.4.2. If the Offerer wishes the Answerer to select the
address assigned to the added "m=" as the Offerer's BUNDLE address,
the mid value associated with the "m=" line is placed first in the
list, according to the procedures in Section 6.4.2.
Section 10.3 shows an example of an Offer used to add an "m=" line to
a BUNDLE group.
6.4.5. Moving A Media Description Out Of A BUNDLE Group
When an Offerer generates an Offer, in which an "m=" line is moved
out of a BUNDLE group, the Offerer MUST assign a unique address to
the moved "m=" line. In addition, the Offerer MUST NOT anymore
include a mid value, representing the "m=" line, in the SDP
group:BUNDLE attribute mid list associated with the BUNDLE group.
Section 10.4 shows an example of an Offer used to move an "m=" line
out of a BUNDLE group.
6.4.6. Disabling A Media Description In A BUNDLE Group
When an Offerer generates an Offer, in which an "m=" line associated
with a BUNDLE group is disabled, the Offerer MUST assign an address
with a zero port value [RFC4566] to the disabled "m=" line. In
addition, the Offerer MUST NOT anymore include a mid value,
representing the "m=" line, in the SDP group:BUNDLE attribute mid
list associated with the BUNDLE group.
OPEN ISSUE (Q8): It still needs to be decided whether a zero port
value can be assigned to a 'bundle-only' "m=" line.
o (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12075.html)
o (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12226.html)
o (http://www.ietf.org/mail-archive/web/mmusic/current/
msg12339.html)
Section 10.5 shows an example of an Offer used to disable an "m="
line in a BUNDLE group.
6.5. SDP Answerer Procedures
Holmberg, et al. Expires April 17, 2014 [Page 9]
Internet-Draft Bundled media October 2013
6.5.1. Offerer Bundle Address Selection
When an Answerer generates an Answer that contains a BUNDLE group,
the Answer MUST select the Offerer's BUNDLE address. The first mid
value in the SDP group:BUNDLE attribute mid list of the Offer
represents the address which the Offerer wishes the Answer to select
as the Offerer's BUNDLE address Section 6.4.2.
The Answerer SHOULD select the address represented by the first mid
value, unless the Answerer in the associated Answer will reject the
"m=" line associated with the mid value, or remove the "m=" line from
the BUNDLE group. In such case the Answerer MUST select an address
associated with the first unrejected mid value that remains in the
SDP group:BUNDLE attribute mid list of the Offer.
In the SDP Answer, the Answerer MUST place the mid value associated
with the selected Offerer's BUNDLE address first in the SDP
group:BUNDLE attribute mid list associated with the BUNDLE group.
Section 10.1 shows an example of an Offerer's BUNDLE address
selection.
6.5.2. Anwerer Bundle Address Selection
When an Answerer creates an Answer that contains a BUNDLE group, the
Answerer MUST assign a local shared address, the Answerer's BUNDLE
address, to each "m=" line within the BUNDLE group.
The Answerer is allowed to change its BUNDLE address in any SDP
Answer.
The Answerer MUST NOT assign a shared address, that it has assigned
to an "m=" line within a BUNDLE group, to an "m=" line outside the
BUNDLE group.
Section 10.1 shows an example of an Answerer's local BUNDLE address
selection.
6.5.3. Moving A Media Description Out Of A BUNDLE Group
When an Answerer generates an Answer, in which an "m=" line is moved
out of a BUNDLE group, the Answerer assigns an address to the moved
"m=" line based on the type of address that the Offerer assigned to
the associated "m=" line in the associated Offer, as described below.
If the Offerer assigned a shared address to the "m=" line, the
answerer MUST reject the moved "m=" line, according to the procedures
in Section 6.5.4.
Holmberg, et al. Expires April 17, 2014 [Page 10]
Internet-Draft Bundled media October 2013
If the Offerer assigned an SDP 'bundle-only' attribute to the "m="
line, the Answerer MUST reject the moved "m=" line, according to the
procedures in Section 6.5.4.
If the Offerer assigned a unique address to the "m=" line, the Answer
MUST assign a unique address to the moved "m=" line.
In addition, in either case above, the Answerer MUST NOT anymore
include a mid value, representing the "m=" line, in the SDP
group:BUNDLE attribute list associated with the BUNDLE group.
6.5.4. Rejecting A Media Description In A BUNDLE Group
When an Answerer generates an Answer, in which an "m=" line
associated with a BUNDLE group is rejected, the Answerer MUST assign
an address with a zero port value to the rejected "m=" line,
according to the procedures in [RFC4566]. In addition, the Answerer
MUST NOT anymore include a mid value, representing the "m=" line, in
the SDP group:BUNDLE attribute midlist associated with the BUNDLE
group.
7. Single vs Multiple RTP Sessions
7.1. General
By default, all RTP based media flows within a given BUNDLE group
belong to a single RTP session [RFC3550]. Multiple BUNDLE groups
will form multiple RTP Sessions.
The usage of multiple RTP Sessions within a given BUNDLE group, or
the usage of a single RTP Session that spans over multiple BUNDLE
groups, is outside the scope of this specification. Other
specification needs to extend the BUNDLE mechanism in order to allow
such usages.
7.2. Single RTP Session
When a single RTP Session is used, media associated with all "m="
lines part of a bundle group share a single SSRC [RFC3550] numbering
space.
In addition, the following rules and restrictions apply for a single
RTP Session:
o The dynamic payload type values used in the "m=" lines MUST NOT
overlap.
Holmberg, et al. Expires April 17, 2014 [Page 11]
Internet-Draft Bundled media October 2013
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
that originates from different "m=" lines.
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].
8. Usage With ICE
8.1. General
This section describes how to use the BUNDLE grouping extension
together with the Interactive Connectivity Establishment (ICE)
mechanism [RFC5245].
8.2. Candidates
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.
When an ICE-enabled endpoint generates and SDP Answer, which contains
a BUNDLE group, the Answerer MUST include ICE candidates for each
"m=" line associated with the "BUNDLE" group, except for any "m="
line where the port number value is set to zero. The Answerer MUST
insert identical candidate values in each "m=" line associated with
the BUNDLE group.
8.3. Candidates
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.
9. Security Considerations
Holmberg, et al. Expires April 17, 2014 [Page 12]
Internet-Draft Bundled media October 2013
This specification does not significantly change the security
considerations of SDP which can be found in Section X of TBD.
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.
10. Examples
10.1. Example: Bundle Address Selection
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
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
SDP Answer (2)
Holmberg, et al. Expires April 17, 2014 [Page 13]
Internet-Draft Bundled media October 2013
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
SDP Offer (3)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
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.
Holmberg, et al. Expires April 17, 2014 [Page 14]
Internet-Draft Bundled media October 2013
SDP Offer (1)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
SDP Answer (2)
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 20000 RTP/AVP 0
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32
b=AS:1000
a=rtpmap:32 MPV/90000
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.
Holmberg, et al. Expires April 17, 2014 [Page 15]
Internet-Draft Bundled media October 2013
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
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar zen
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
m=video 20000 RTP/AVP 66
a=mid:zen
b=AS:1000
a=rtpmap:66 H261/90000
SDP Answer (2)
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE foo bar zen
m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000
Holmberg, et al. Expires April 17, 2014 [Page 16]
Internet-Draft Bundled media October 2013
a=rtpmap:32 MPV/90000
m=video 20000 RTP/AVP 66
a=mid:zen
b=AS:1000
a=rtpmap:66 H261/90000
SDP Offer (3)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar zen
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
m=video 10000 RTP/AVP 66
a=mid:zen
b=AS:1000
a=rtpmap:66 H261/90000
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.
Holmberg, et al. Expires April 17, 2014 [Page 17]
Internet-Draft Bundled media October 2013
SDP Offer (1)
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
m=video 50000 RTP/AVP 66
b=AS:1000
a=rtpmap:66 H261/90000
SDP Answer (2)
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
m=video 60000 RTP/AVP 66
b=AS:1000
a=rtpmap:66 H261/90000
Holmberg, et al. Expires April 17, 2014 [Page 18]
Internet-Draft Bundled media October 2013
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
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
m=video 0 RTP/AVP 66
a=rtpmap:66 H261/90000
SDP Answer (2)
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE foo bar
Holmberg, et al. Expires April 17, 2014 [Page 19]
Internet-Draft Bundled media October 2013
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
extension called BUNDLE.
12. Acknowledgements
The usage of the SDP grouping extension for negotiating bundled media
is based on a similar alternatives proposed by Harald Alvestrand and
Cullen Jennings. The BUNDLE mechanism described in this document is
based on the different alternative proposals, and text (e.g. SDP
examples) have been borrowed (and, in some cases, modified) from
those alternative proposals.
The SDP examples are also modified versions from the ones in the
Alvestrand proposal.
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]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04
o Updated Offerer procedures (http://www.ietf.org/mail-archive/web/
mmusic/current/msg12293.html).
o Updated Answerer procedures (http://www.ietf.org/mail-archive/web/
mmusic/current/msg12333.html).
o Usage of SDP 'bundle-only' attribute added.
Holmberg, et al. Expires April 17, 2014 [Page 20]
Internet-Draft Bundled media October 2013
o Reference to Trickle ICE document added.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02
o 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.
o Cullen Jennings added as co-author.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01
o No changes. New version due to expiration.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00
o No changes. New version due to expiration.
Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00
o Draft name changed.
o Harald Alvestrand added as co-author.
o "Multiplex" terminology changed to "bundle".
o Added text about single versus multiple RTP Sessions.
o Added reference to RFC 3550.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
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.
Holmberg, et al. Expires April 17, 2014 [Page 21]
Internet-Draft Bundled media October 2013
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[I-D.nandakumar-mmusic-sdp-mux-attributes]
Nandakumar, S. and C. Jennings, "A Framework for SDP
Attributes when Multiplexing ", draft-nandakumar-mmusic-
sdp-mux-attributes-04 (work in progress), September 2013.
14.2. Informative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
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
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol ", draft-ietf-
mmusic-trickle-ice-00 (work in progress), October 2013.
Appendix A. Design Considerations
A.1. General
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.
Below are the primary issues that have been considered when defining
the "BUNDLE" grouping extension:
o 1) Interoperability with existing UAs.
o 2) Interoperability with intermediary B2BUA- and proxy entities.
Holmberg, et al. Expires April 17, 2014 [Page 22]
Internet-Draft Bundled media October 2013
o 3) Time to gather, and the number of, ICE candidates.
o 4) Different error scenarios, and when they occur.
o 5) SDP Offer/Answer impacts, including usage of port number value
zero.
NOTE: Before this document is published as an RFC, this
Appendix might be removed.
A.2. UA Interoperability
Consider the following SDP Offer/Answer exchange, where Alice sends
an SDP Offer to Bob:
SDP Offer
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 97
a=rtpmap:97 H261/90000
SDP Answer
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 20000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 20002 RTP/AVP 97
a=rtpmap:97 H261/90000
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
Holmberg, et al. Expires April 17, 2014 [Page 23]
Internet-Draft Bundled media October 2013
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:
SDP Offer
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 98
a=rtpmap:98 H261/90000
will result in the second "m=" line being considered an SDP error
because it has the same port as the first line.
A.3. Usage of port number value zero
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.
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.
Holmberg, et al. Expires April 17, 2014 [Page 24]
Internet-Draft Bundled media October 2013
A.4. B2BUA And Proxy Interoperability
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:
SDP Offer
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtcp:53020
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.
A.4.1. Traffic Policing
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.
A.4.2. Bandwidth Allocation
Sometimes intermediaries do not act as B2BUA, in the sense that they
don't modify SDP bodies, nor do they terminate SIP dialogs. Still,
Holmberg, et al. Expires April 17, 2014 [Page 25]
Internet-Draft Bundled media October 2013
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.
A.5. Candidate Gathering
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
[I-D.ietf-mmusic-trickle-ice] to get the non host ICE candidates for
the rest of the "m=" lines, it MAY do that and will not need any
additional gathering time.
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.
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Harald Tveit Alvestrand
Google
Kungsbron 2
Stockholm 11122
Sweden
Email: harald@alvestrand.no
Holmberg, et al. Expires April 17, 2014 [Page 26]
Internet-Draft Bundled media October 2013
Cullen Jennings
Cisco
400 3rd Avenue SW, Suite 350
Calgary, AB T2P 4H2
Canada
Email: fluffy@iii.ca
Holmberg, et al. Expires April 17, 2014 [Page 27]
