draft-ietf-mmusic-sdp-bundle-negotiation-02.txt   draft-ietf-mmusic-sdp-bundle-negotiation-03.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 16, 2013 Google Expires: August 22, 2013 Google
February 12, 2013 C. Jennings
Cisco
February 18, 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-02.txt draft-ietf-mmusic-sdp-bundle-negotiation-03.txt
Abstract Abstract
This specification defines a new SDP Grouping Framework SDP grouping This specification defines a new SDP Grouping Framework extension,
framework extension, "BUNDLE", that can be used with the Session "BUNDLE", that can be used with the Session Description Protocol
Description Protocol (SDP) Offer/Answer mechanism to negotiate the (SDP) Offer/Answer mechanism to negotiate the usage of bundled media,
usage of bundled media, which refers to the usage of a single 5-tuple which refers to the usage of a single 5-tuple for media associated
for media associated with multiple SDP media descriptions ("m=" with multiple SDP media descriptions ("m=" lines).
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 to IETF 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 16, 2013. This Internet-Draft will expire on August 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 4 5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 4
6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. SDP Offerer Procedures . . . . . . . . . . . . . . . . . . 5 6.2. SDP Offerer Procedures . . . . . . . . . . . . . . . . . . 5
6.3. SDP Answerer Procedures . . . . . . . . . . . . . . . . . 6 6.3. SDP Answerer Procedures . . . . . . . . . . . . . . . . . 7
6.4. Bundled SDP Information . . . . . . . . . . . . . . . . . 6 6.4. Bundled SDP Information . . . . . . . . . . . . . . . . . 7
6.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 6.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
6.4.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . 6 6.4.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . 7
7. Single vs Multiple RTP Sessions . . . . . . . . . . . . . . . 6 6.4.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . 7
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Single vs Multiple RTP Sessions . . . . . . . . . . . . . . . 8
7.2. Single RTP Session . . . . . . . . . . . . . . . . . . . . 6 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2. Single RTP Session . . . . . . . . . . . . . . . . . . . . 8
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . . 8
8.2. Candidates . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8.2. Candidates . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.3. Candidates . . . . . . . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. Example: SDP Offer with different port number values . . . . . 9
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Example: SDP Offer with identical port number values . . . . . 11
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14.1. Normative References . . . . . . . . . . . . . . . . . . . 10 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
14.2. Informative References . . . . . . . . . . . . . . . . . . 11 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Design Considerations . . . . . . . . . . . . . . . . 15
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 15
A.3. Usage of port number value zero . . . . . . . . . . . . . 16
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . . 17
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . . 18
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . . 18
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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 SDP grouping This specification defines a new SDP Grouping Framework [RFC5888]
framework [RFC5888] extension, "BUNDLE", that can be used with the extension, "BUNDLE", that can be used with the Session Description
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate the
to negotiate the usage of bundled media, which refers to the usage of usage of bundled media, which refers to the usage of a single 5-tuple
a single 5-tuple for media associated with multiple SDP media for media associated with multiple SDP media descriptions ("m="
descriptions ("m=" lines). lines).
When an endpoint generates an SDP Offer or SDP Answer [RFC3264], The SDP Offerer and SDP Answerer [RFC3264] use the "BUNDLE" grouping
which includes a "BUNDLE" group, each "m=" line associated with the extension to indicate which media is associated with a single
group will share a single port number value. 5-tuple. For each media, the associated "m=" line is associated with
a "BUNDLE" group.
As defined in RFC 4566 [RFC4566], the semantics of multiple "m=" For each "BUNDLE" group, the SDP Offerer and SDP Answerer use an
lines using the same port number value are undefined, and there is no identical port number value in each "m=" line associated with the
grouping defined by such means. Instead, an explicit grouping "BUNDLE" group. However, until it is known that the SDP Answerer
supports the "BUNDLE" grouping extension, when the SDP Offerer
generates an SDP Offer, a different port number value is inserted for
each "m=" line associated with the "BUNDLE" group. The port number
value associated with the first "m=" line associated with the
"BUNDLE" group represents the port value number offered to be used in
the single 5-tuple.
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 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
each "BUNDLE" group, a different port number value MUST be used.
When media is transported using the Real-Time Protocol (RTP) When media is transported using the Real-Time Protocol (RTP)
[RFC3550], the default assumption of the mechanism is that all media [RFC3550], the default assumption of the mechanism is that all media
associated with a "BUNDLE" group will form a single RTP Session associated with a "BUNDLE" group will form a single RTP Session
[RFC3550]. However, future specifications can extend the mechanism, [RFC3550]. However, future specifications can extend the mechanism,
in order to negotiate RTP Session multiplexing, i.e. "BUNDLE" groups in order to negotiate RTP Session multiplexing, i.e. "BUNDLE" groups
where media associated with a group form multiple RTP Sessions. where media associated with a group form multiple RTP Sessions.
The mechanism is backward compatible. Entities that do not support The mechanism is backward compatible. Endpoints that do not support
the "BUNDLE" grouping extension, or do not want to enable the the "BUNDLE" grouping extension are expected to generate SDP Offers
mechanism for a given session, are expected to generate a "normal" and SDP Answers without inserting a "BUNDLE" group, and to insert
SDP Answer, using different port number values for each "m=" line, to different port number values in each "m=" line, in the SDP Offers and
the SDP Offer. The SDP Offerer [RFC3264] will still use a single SDP Answers, as defined in RFC 4566 and RFC 3264.
port number value for each media, but as the SDP Answerer [RFC3264]
will use separate ports a single 5-tuple will not be used for media
associated with multiple "m=" lines between the endpoints.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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.
3. Conventions 3. Conventions
skipping to change at page 4, line 38 skipping to change at page 5, line 4
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 an SDP media-level 'mid' attribute, is part
of a specific "BUNDLE" group. of a specific "BUNDLE" group.
6. SDP Offer/Answer Procedures 6. SDP Offer/Answer Procedures
6.1. General 6.1. General
When an SDP Offerer or SDP Answerer generates an SDP Offer or SDP When an endpoint generates an SDP Offer or SDP Answer, which contains
Answer, that describes bundled media, it MUST insert an SDP session- a "BUNDLE" group, it MUST insert an SDP session-level 'group'
level 'group' attribute, with a "BUNDLE" value, and assign SDP media- attribute, with a "BUNDLE" value, and assign SDP media-level 'mid'
level 'mid' attribute values to each "m=" line associated with the attribute values for each "m=" line associated the "BUNDLE" group.
"BUNDLE" group.
In addition, the entity that generates the SDP Offer or SDP Answer Until it is known whether the SDP Answerer supports the "BUNDLE"
MUST, for each "m=" line that is part of the "BUNDLE" group: grouping extension, the SDP Offerer MUST, for each "m=" line
associated with a "BUNDLE" group:
o 1. Use the same port number value. o 1. Insert different port number values.
o 2. Use the same connection data ("c=" line) value. o 2. Insert identical connection data ("c=" line) value.
o 3. Use the same SDP 'rtcp' attribute value, when used. o 3. Insert different SDP 'rtcp' attribute value, when used.
o 4. Use the same ICE candidate values, when used. o 4. Insert different ICE candidate values, when used.
o 5. Insert an SDP 'rtpc-mux' attribute. 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
NOTE: If an entity wants to disable specific media ("m=" line) Once it is known that both endpoints support the "BUNDLE" grouping
associated with a "BUNDLE" group, it will use a zero port number extension, the SDP Offerer and SDP Answerer MUST, for each "m=" line
value for the "m=" line associated with the media. associated with a "BUNDLE" group:
o 1. Insert identical port number values.
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
extension, they can start using the single port for the media
associated with each "m=" line in the "BUNDLE group".
OPEN ISSUE #1: If the SDP Answerer supports "BUNDLE", do we mandate
that "m=" lines must be grouped in the same way in the SDP Answer as
they are grouped in the SDP Offer?
6.2. SDP Offerer Procedures 6.2. SDP Offerer Procedures
When an SDP Offerer creates an SDP Offer, that offers bundled media, When the SDP Offerer generates an SDP Offer that contains a "BUNDLE"
it MUST create the SDP Offer according to the procedures in group, the SDP Offer MUST be generated according to the procedures in
Section 6.1. Section 6.1.
If the associated SDP Answer contains an SDP session-level 'group' If the associated SDP Answer contains a "BUNDLE" group, and the SDP
attribute, with a "BUNDLE" value, and the SDP Answer is created Offer contained different port number values in each "m=" line
according to the proceudres in Section 6.1 (the same port number associated with the "BUNDLE" group, the SDP Offerer MUST generate a
value is used for each "m=" line associated with the "BUNDLE" group, new SDP Offer, and insert an identical port number value for each
etc), the SDP Offerer can start using the same 5-tuple for sending "m=" line associated with the "BUNDLE" group. Unless ICE is used,
and receiving media, associated with the group, between the entities. 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.
If the SDP Answer does not include a session-level SDP 'group' NOTE: The reason for sending the new SDP Offer, which includes an
attribute, with a "BUNDLE" value, the SDP Offerer cannot use the same identical port number value in each "m=" line associated with the
5-tuple for media associated with multiple "m=" lines. "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 Answererer indicates that it will not use bundled media, If the SDP Offer contains different port number values for each "m="
the SDP Offerer will still use the single port number value for each lines associated with the "BUNDLE" group, and if the associated SDP
"m= line" associated with the offered "BUNDLE" group, and it will Answer does not contain a "BUNDLE" group, the SDP Offerer MUST use
normally be able to separate each individual media. The default the different port number values that were included in the SDP Offer.
mechanism for separating media received on a single IP address and
port doing this is by using a 5-tuple based mapping for each
individual media. If the SDP Offerer is aware of the Synchronization
Source (SSRC) [RFC3550] values that the SDP Answerer will use in the
media it sends, and the SSRC values will be unique for each media,
the SDP Offerer can separate media based on the SSRC values.
NOTE: Assuming symmetric media is used, the SDP Offerer can use the Once it is known that both the SDP Offerer and SDP Answerer support
port information from the SDP Answer in order to create the 5-tuple the "BUNDLE" grouping extension, in each subsequent SDP Offer towards
mapping for each media. the SDP Answerer, the SDP Offer MUST insert an identical port number
value in each "m=" line associated with the "BUNDLE" group.
If the SDP Offerer is not able to separate multiple media received on NOTE: If needed, the SDP Offerer is allowed to change the port number
a single port, it MUST send a new SDP Offer, without offering bundled value in an subsequent SDP Offer, but it still inserts the same
media, where a separate port number value is provide for each "m=" identical port number value in each "m=" line associated with the
line of the SDP Offer. "BUNDLE" group.
If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has When generating an SDP Offer, if the SDP Offerer wants to disable
reasons to believe that the rejection is due to the usage of a single media associated with an "m=" line in a "BUNDLE" group, it will
port number value for multiple "m=" lines, the SDP Offerer SHOULD insert a zero port number value in the disabled "m=" line, as defined
send a new SDP Offer, without a "BUNDLE" group, where a separate port in RFC 3264. However, if the "m=" lines associated with the "BUNDLE"
number value is provide for each "m=" line of the SDP offer. 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
multiple "m=" lines, unless the "m=" lines are associated with a
"BUNDLE" group.
OPEN ISSUE #2: If the session has been established without BUNDLE, do
we allow BUNDLE to be enabled later during the session?
OPEN ISSUE #3: If the session has been established with BUNDLE, do we
allow BUNDLE to be disabled later during the session, meaning that
different port number values will be used for media associated with
each "m=" line?
6.3. SDP Answerer Procedures 6.3. SDP Answerer Procedures
When an SDP Answerer receives an SDP Offer, which offers bundled When an SDP Answerer receives an SDP Offer which contains a "BUNDLE"
media, and the SDP Answerer accepts the offered bundle group, the SDP group, and the SDP Answerer accepts the offered "BUNDLE" group, the
Answerer MUST create an SDP Answer according to the procedures in SDP Answerer MUST generate an SDP Answer according to the procedures
Section 6.1. in Section 6.1.
If the SDP Answerer does not accept the "BUNDLE" group in the SDP When generating the SDP Answer, if the SDP Answerer wants to reject
Offer, it MUST NOT include a session-evel 'group' attribute, with a media associated with an "m=" line in the "BUNDLE" group, it will
"BUNDLE" value, in the associated SDP Answer. In addition, the SDP insert a zero port number value in the disabled "m=" line, as defined
Answerer MUST provide separate port number values for each "m=" line in RFC 3264.
of the SDP Answer.
The SDP Answerer MUST NOT insert a "BUNDLE" group in an SDP Answer,
unless the associated SDP Offer contains a "BUNDLE" group.
The SDP Answerer MUST NOT insert an identical port number value in
multiple "m=" lines, unless the "m=" lines are associated with a
"BUNDLE" group.
Until the SDP Answerer receives the new SDP Offer, which contains an
identical port number value for each "m=" line associated with a
"BUNDLE" group, it MUST use the port, and related information (ICE
candidates, SDES keys etc) associated with the first "m=" line in the
"BUNDLE" group.
6.4. Bundled SDP Information 6.4. Bundled SDP Information
6.4.1. General 6.4.1. General
This section describes how SDP information, given for each media This section describes how SDP information, given for each media
description, is calculated into a single value for a "BUNDLE" group. description, is calculated into a single value for a "BUNDLE" group.
6.4.2. Bandwidth (b=) 6.4.2. Bandwidth (b=)
The total proposed bandwidth is the sum of the proposed bandwidth for The total proposed bandwidth is the sum of the proposed bandwidth for
each "m=" line associated with a negotiated BUNDLE group. each "m=" line associated with a negotiated BUNDLE group.
6.4.3. Attributes (a=)
There are also special rules for handling many different attributes
as defined in [I-D.nandakumar-mmusic-sdp-attributes]. It might not
possible to use bundle with some attributes.
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 When entities negotiate the usage of bundled media, the default
assumption is that all media associated with the bundled media will assumption is that all media associated with the bundled media will
form a single RTP session. form a single RTP session.
The usage of multiple RTP Sessions within a "BUNDLE" group is outside The usage of multiple RTP Sessions within a "BUNDLE" group is outside
the scope of this specification. Other specification needs to extend the scope of this specification. Other specification needs to extend
the mechanism in order to allow negotiation of such bundle groups. the mechanism in order to allow negotiation of such bundle groups.
It is possible to use multiple "BUNDLE" groups, in case the RTP media
within each group will be part of different RTP Sessions.
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
skipping to change at page 7, line 26 skipping to change at page 8, line 46
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 mechanism 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 SDP Offerer sends an SDP offer, it MUST include When an ICE-enabled endpoint generates an SDP Offer, which contains a
ICE candidates for each "m=" line associated with a "BUNDLE" group. "BUNDLE" group, the SDP Offerer MUST include ICE candidates for each
The candidate values MUST be identical for each "m=" line associated "m=" line associated with a "BUNDLE" group, except for any "m=" line
with the group. This rule applies also to subsequent SDP Offers, with a zero port number value. If the "m=" lines associated with the
when the usage of bundled media has already been negotiated. "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 SDP Answerer receives an SDP Offer, offering a When an ICE-enabled endpoint generates and SDP Answer, which contains
"BUNDLE" group and ICE, if the SDP Answerer enables ICE, MUST include a "BUNDLE" group, the SDP Answerer MUST include ICE candidates for
ICE candidates for each "m=" line of the SDP Answer. This also each "m=" line associated with the "BUNDLE" group, except for any
applies for "m=" lines that are part of a "BUNDLE" group, in which "m=" line where the port number value is set to zero. The SDP
case the candidate values MUST be identical for each "m=" line Answerer MUST insert identical candidate values in each "m=" line
associated with the group. This rule applies also to subsequent SDP associated with the "BUNDLE" group.
Answers, when the usage of bundled media has already been negotiated.
Once the usage of bundled media has been negotiated, ICE connectivity 8.3. Candidates
checks and keep-alives only needs to be performed for the whole
"BUNDLE" group, instead of for each individual m= line associated Once it is known that both endpoints support, and accept to use, the
with the group. "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 9. Security Considerations
TBA This specification does not significantly change the security
considerations of SDP which can be found in Section X of TBD.
10. Example 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.
The example below shows an SDP Offer, where bundled media is offered. 10. Example: SDP Offer with different port number values
The example also shows two SDP Answer alternatives: one where bundled
media is accepted, and one where bundled media is rejected (or, not The example below shows an SDP Offer, where bundled media is offered
even supported) by the SDP Answerer. 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)
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s=
c=IN IP4 host.atlanta.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
SDP Answer (Bundled media accepted)
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
s=
c=IN IP4 host.biloxi.com
t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
SDP Answer (Bundled media not accepted)
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
s=
c=IN IP4 host.biloxi.com
t=0 0
m=audio 20000 RTP/AVP 0
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32
b=AS:1000
a=rtpmap:32 MPV/90000
SDP Offer with ICE (Bundled media offered)
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s=
c=IN IP4 host.atlanta.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=candidate:1 1 UDP 1694498815 host.atlanta.com 10002 typ host
11. Example: SDP Offer with identical port number values
The example below shows an SDP Offer, where bundled media is offered
an identical port number value in the "m=" lines associated with the
"BUNDLE" group. The example also shows two SDP Answer alternatives:
one where bundled media is accepted, and one where bundled media is
rejected (or, not even supported) by the SDP Answerer.
SDP Offer (Bundled media offered) SDP Offer (Bundled media offered)
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
skipping to change at page 10, line 5 skipping to change at page 13, line 31
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 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 a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
11. IANA Considerations 12. 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.
12. Acknowledgements 13. Acknowledgements
The usage of the SDP grouping mechanism is based on a similar
alternative proposed by Harald Alvestrand. The SDP examples are also
modified versions from the ones in the Alvestrand proposal.
Thanks to the nice flight crew on AY 021 for providing good sparkling The usage of the SDP grouping extension for negotiating bundled media
wine, and a nice working athmosphere, for working on this draft. is based on a similar alternative proposed by Harald Alvestrand. The
SDP examples are also modified versions from the ones in the
Alvestrand proposal.
13. Change Log 14. 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
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 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. o Added reference to RFC 3550.
14. References 15. References
14.1. Normative References 15.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 2002. June 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.
[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.
14.2. Informative References [I-D.nandakumar-mmusic-sdp-attributes]
Nandakumar, S. and C. Jennings, "A Framework for SDP
Attributes when Multiplexing",
draft-nandakumar-mmusic-sdp-attributes-00 (work in
progress), February 2013.
15.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.
[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 2010. April 2010.
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.
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 host.atlanta.com
s=
c=IN IP4 host.atlanta.com
t=0 0
m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 10002 RTP/AVP 97
a=rtpmap:97 H261/90000
SDP Answer
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
s=
c=IN IP4 host.biloxi.com
t=0 0
m=audio 20000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 20002 RTP/AVP 97
a=rtpmap:97 H261/90000
RFC 4961 specifies a way of doing symmetric RTP but that is an a
later invention to RTP and Bob can not assume that Alice supports RFC
4961. This means that Alice may be sending RTP from a different port
than 10000 or 10002 - some implementation simply send the RTP from an
ephemeral port. When Bob's endpoint receives an RTP packet, the only
way that Bob know if it should be passed to the video or audio codec
is by looking at the port it was received on. This lead some SDP
implementations to use the fact that each "m=" line had a different
port number to use that port number as an index to find the correct m
line in the SDP. As a result, some implementations that do support
symmetric RTP and ICE still use a SDP data structure where SDP with
"m=" lines with the same port such as:
SDP Offer
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
s=
c=IN IP4 host.atlanta.com
t=0 0
m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 98
a=rtpmap:98 H261/90000
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.
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 host.atlanta.com
s=
c=IN IP4 host.atlanta.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,
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 [TODO REF] to get the
non host ICE candidates for the rest of the "m=" lines, it MAY do
that and will not need any additional gathering time.
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 Authors' Addresses
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
Harald Tveit Alvestrand Harald Tveit Alvestrand
Google Google
Kungsbron 2 Kungsbron 2
Stockholm 11122 Stockholm 11122
Sweden Sweden
Email: harald@alvestrand.no Email: harald@alvestrand.no
Cullen Jennings
Cisco
400 3rd Avenue SW, Suite 350
Calgary, AB T2P 4H2
Canada
Email: fluffy@iii.ca
 End of changes. 47 change blocks. 
147 lines changed or deleted 492 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/