draft-ietf-mmusic-sdp-bundle-negotiation-09.txt   draft-ietf-mmusic-sdp-bundle-negotiation-10.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264 (if approved) H. Alvestrand Updates: 3264 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: March 9, 2015 C. Jennings Expires: March 14, 2015 C. Jennings
Cisco Cisco
September 5, 2014 September 10, 2014
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-09.txt draft-ietf-mmusic-sdp-bundle-negotiation-10.txt
Abstract Abstract
This specification defines a new SDP Grouping Framework extension, This specification defines a new SDP Grouping Framework extension,
'BUNDLE'. The BUNDLE extension can be used with the Session 'BUNDLE'. The extension can be used with the Session Description
Description Protocol (SDP) Offer/Answer mechanism to negotiate the Protocol (SDP) Offer/Answer mechanism to negotiate the usage of a
usage of a single 5-tuple for sending and receiving media, referred single 5-tuple for sending and receiving media associated with
to as bundled media, associated with multiple SDP media descriptions multiple SDP media descriptions ("m="). This is referred to as
("m=" lines). This specification also defines a new SDP attribute, bundled media. This specification also defines a new SDP attribute,
'bundle-only', which can be used to request that specific media is 'bundle-only', which can be used to request that specific media is
only used if bundled. only used if bundled.
This specification also updates sections 5.1, 8.1 and 8.2 of RFC This specification also updates sections 5.1, 8.1 and 8.2 of RFC
3264. The update allows an answerer to assign a non-zero port value 3264. The update allows an answerer to assign a non-zero port value
to an "m=" line in an answer, even if the "m=" line in the associated to an "m=" line in an SDP answer, even if the "m=" line in the
offer contained a zero port value. associated SDP offer contained a zero port value.
Status of This Memo Status of This Memo
This Internet-Draft is submitted 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 March 9, 2015. This Internet-Draft will expire on March 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 52 skipping to change at page 2, line 52
8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
8.3.2. Answerer Selection of Offerer Bundle Address . . . . 11 8.3.2. Answerer Selection of Offerer Bundle Address . . . . 11
8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 12 8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 12
8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 12 8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 12
8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 12 8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 12
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 13 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 13
8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 13
8.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 13 8.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 13
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 14 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 14
8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 14 8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 14
8.5.2. Request new offerer BUNDLE address . . . . . . . . . 15 8.5.2. Request a new offerer BUNDLE address . . . . . . . . 15
8.5.3. Adding a media description to a BUNDLE group . . . . 15 8.5.3. Adding a media description to a BUNDLE group . . . . 15
8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 16 8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 16
8.5.5. Disabling A Media Description In A BUNDLE Group . . . 16 8.5.5. Disabling A Media Description In A BUNDLE Group . . . 16
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 16 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 16
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17
10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 17 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 17
10.1.2. Payload Type (PT) Value Re-usage . . . . . . . . . . 18 10.1.2. Payload Type (PT) Value Re-usage . . . . . . . . . . 18
skipping to change at page 4, line 18 skipping to change at page 4, line 18
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
19.1. Normative References . . . . . . . . . . . . . . . . . . 38 19.1. Normative References . . . . . . . . . . . . . . . . . . 38
19.2. Informative References . . . . . . . . . . . . . . . . . 38 19.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Design Considerations . . . . . . . . . . . . . . . 39 Appendix A. Design Considerations . . . . . . . . . . . . . . . 39
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 39 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 40 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 40
A.3. Usage of port number value zero . . . . . . . . . . . . . 41 A.3. Usage of port number value zero . . . . . . . . . . . . . 41
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 41 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 41
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 42 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 42
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 42 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 42
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 42 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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. candidates for multiple media descriptions.
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension, 'BUNDLE'. The BUNDLE extension can be used with the extension , 'BUNDLE'. The extension can be used with the Session
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Description Protocol (SDP) Offer/Answer mechanism [RFC3264] to
to negotiate the usage of a single 5-tuple for sending and receiving negotiate the usage of a single 5-tuple for sending and receiving
media, referred to as bundled media, associated with multiple SDP media associated with multiple SDP media descriptions ("m="). This
media descriptions ("m="). This specification also defines a new SDP is referred to as bundled media. This specification also defines a
attribute, 'bundle-only', which can be used to request that specific new SDP attribute, 'bundle-only', which can be used to request that
media is only used if bundled. specific media is only used if bundled.
The offerer and answerer [RFC3264] use the BUNDLE extension to The offerer and answerer [RFC3264] use the BUNDLE extension to
negotiate the 5-tuples (BUNDLE addresses), one for the offerer negotiate the 5-tuples (BUNDLE addresses), one for the offerer
(offerer BUNDLE address) and one for the answerer (answerer BUNDLE (offerer BUNDLE address) and one for the answerer (answerer BUNDLE
address) to be used for the bundled media associated with a BUNDLE address) to be used for the bundled media associated with a BUNDLE
group. group.
Once the offerer and the answerer have negotiated a BUNDLE group, and Once the offerer and the answerer have negotiated a BUNDLE group, and
the associated BUNDLE addresses, each endpoint can assign its BUNDLE the associated BUNDLE addresses, each endpoint can assign its BUNDLE
address to each "m=" line within, and use the address to send and address to each "m=" line within, and use the address to send and
receive all media associated with, the BUNDLE group. receive all media associated with, the BUNDLE group.
NOTE: As defined in RFC 4566 [RFC4566], the semantics of assigning NOTE: As defined in RFC 4566 [RFC4566], the semantics of assigning
the same port value to multiple "m=" lines are undefined, and there the same port value to multiple "m=" lines 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 an extension. specification provides such an extension.
This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264
[RFC3264]. The update allows an answerer to assign a non-zero port [RFC3264]. The update allows an answerer to assign a non-zero port
value to an "m=" line in an answer, even if the "m=" line in the value to an "m=" line in an SDP answer, even if the "m=" line in the
associated offer contained a zero port value. associated SDP offer contained a zero port value.
SDP bodies can contain multiple BUNDLE groups. A given BUNDLE SDP bodies can contain multiple BUNDLE groups. A given BUNDLE
address MUST only be associated with a single BUNDLE group. address MUST only be associated with a single BUNDLE group.
The procedures in this specification apply independently to a given The procedures in this specification apply independently to a given
BUNDLE group. BUNDLE group.
All Real-time Transport Protocol (RTP) [RFC3550] based media flows All Real-time Transport Protocol (RTP) [RFC3550] based media flows
associated with a single BUNDLE group belong to a single RTP session associated with a single BUNDLE group belong to a single RTP session
[RFC3550]. [RFC3550].
skipping to change at page 6, line 14 skipping to change at page 6, line 14
BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer
exchange, for which each endpoint use a single 5-tuple is to send and exchange, for which each endpoint use a single 5-tuple is to send and
receive media. Each endpoint uses its BUNDLE address, associated receive media. Each endpoint uses its BUNDLE address, associated
with the BUNDLE group, to send and receive the media. with the BUNDLE group, to send and receive the media.
Bundled "m=" line: An "m=" line, which SDP 'mid' attribute value is Bundled "m=" line: An "m=" line, which SDP 'mid' attribute value is
placed in a SDP 'group:BUNDLE' attribute mid value list in an offer placed in a SDP 'group:BUNDLE' attribute mid value list in an offer
or answer. or answer.
Bundle-only "m=" line: A bundled "m=" line, to which an SDP 'bundle- Bundle-only "m=" line: A bundled "m=" line with an associated SDP
only' attribute has been assigned. 'bundle-only' attribute.
Bundled media: All media associated with a given BUNDLE group. Bundled media: All media associated with a given BUNDLE group.
Initial offer: The first offer, within an SDP session, in which the Initial offer: The first offer, within an SDP session, in which the
offerer indicates that it wants to create a given BUNDLE group. offerer indicates that it wants to create a given BUNDLE group.
Subsequent offer: An offer which contains a BUNDLE group that has Subsequent offer: An offer which contains a BUNDLE group that has
been created as part of a previous SDP Offer/Answer exchange. been created as part of a previous SDP Offer/Answer exchange.
3. Conventions 3. Conventions
skipping to change at page 7, line 9 skipping to change at page 7, line 9
BUNDLE group, media described with "m=" lines associated with the BUNDLE group, media described with "m=" lines associated with the
BUNDLE group will be sent and received using a single 5-tuple. BUNDLE group will be sent and received using a single 5-tuple.
The BUNDLE extension is indicated using an SDP 'group' attribute with The BUNDLE extension is indicated using an SDP 'group' attribute with
a "BUNDLE" semantics value [RFC5888]. An SDP "mid" attribute is a "BUNDLE" semantics value [RFC5888]. An SDP "mid" attribute is
assigned to each bundled "m=" line, and the "mid" attribute value is assigned to each bundled "m=" line, and the "mid" attribute value is
listed in the 'group:BUNDLE' attribute mid value list. Each "m=" listed in the 'group:BUNDLE' attribute mid value list. Each "m="
line, which mid value is listed in the mid value list, is associated line, which mid value is listed in the mid value list, is associated
with a given BUNDLE group. with a given BUNDLE group.
Any given "m=" line MUST NOT be associated with more than one BUNDLE SDP bodies can contain multiple BUNDLE groups. Any given bundled
group. "m=" line MUST NOT be associated with more than one BUNDLE group.
Section 8 defines the detailed SDP Offer/Answer procedures for the [Section 8] defines the detailed SDP Offer/Answer procedures for the
BUNDLE extension. BUNDLE extension.
6. SDP 'bundle-only' Attribute 6. SDP 'bundle-only' Attribute
6.1. General 6.1. General
This section defines a new SDP media-level attribute [RFC4566], This section defines a new SDP media-level attribute [RFC4566],
'bundle-only'. 'bundle-only'.
The 'bundle-only' attribute can be assigned to a bundled "m=" line in The 'bundle-only' attribute can be associated with a bundled "m="
an offer, to request that the answerer only accepts the "m=" line if line in an offer, to request that the answerer only accepts the "m="
the answerer keeps the "m=" line within the associated BUNDLE group. line if the answerer keeps the "m=" line within the associated BUNDLE
group.
In order to ensure that an answerer that does not supports the BUNDLE In order to ensure that an answerer that does not supports the BUNDLE
extension always rejects a 'bundle-only' "m=" line, the offerer can extension always rejects a 'bundle-only' "m=" line, the offerer can
assign a zero port value to the "m=" line to which the 'bundle-only' assign a zero port value to the "m=" line. According to [RFC4566] an
attribute has been assigned. According to [RFC4566] an answerer will answerer will reject such "m=" line.
reject such "m=" line.
The usage of the 'bundle-only' attribute is only defined for a The usage of the 'bundle-only' attribute is only defined for a
bundled "m=" line within an offer. Other usage is unspecified. bundled "m=" line within an offer. Other usage is unspecified.
Section 8 defines the detailed SDP Offer/Answer procedures for the [Section 8] defines the detailed SDP Offer/Answer procedures for the
'bundle-only' attribute. 'bundle-only' attribute.
6.2. Syntax 6.2. Syntax
This section defines the Augmented Backus-Naur Form (ABNF) [RFC5234] This section defines the Augmented Backus-Naur Form (ABNF) [RFC5234]
for the SDP 'bundle-only' attribute, based on the SDP [RFC4566] for the SDP 'bundle-only' attribute, based on the SDP [RFC4566]
grammar. grammar.
attribute =/ bundle-only-attribute attribute =/ bundle-only-attribute
skipping to change at page 8, line 41 skipping to change at page 8, line 41
The total proposed bandwidth for a BUNDLE group is the sum of the The total proposed bandwidth for a BUNDLE group is the sum of the
proposed bandwidth for each bundled "m=" line. proposed bandwidth for each bundled "m=" line.
The total proposed bandwidth for an offer or answer is the sum of the The total proposed bandwidth for an offer or answer is the sum of the
proposed bandwidth for each "m=" line (bundled and non-bundled) proposed bandwidth for each "m=" line (bundled and non-bundled)
within the offer or answer. within the offer or answer.
7.4. Attributes (a=) 7.4. Attributes (a=)
[I-D.mmusic-sdp-mux-attributes] defines rules and restrictions for An offerer and answerer MUST use the rules and restrictions defined
assigning different types of SDP attributes to a bundled "m=" line. in [I-D.mmusic-sdp-mux-attributes] for when associating SDP
attributes with bundled "m=" lines.
8. SDP Offer/Answer Procedures 8. SDP Offer/Answer Procedures
8.1. General 8.1. General
This section describes the SDP Offer/Answer [RFC3264] procedures for: This section describes the SDP Offer/Answer [RFC3264] procedures for:
o Negotiating and creating of a BUNDLE group; o Negotiating and creating of a BUNDLE group;
o Selecting the BUNDLE addresses (offerer BUNDLE address and o Selecting the BUNDLE addresses (offerer BUNDLE address and
answerer BUNDLE address); answerer BUNDLE address);
skipping to change at page 9, line 30 skipping to change at page 9, line 30
The procedures in this section are independent of the media type or The procedures in this section are independent of the media type or
transport protocol represented by a bundled "m=" line. [Section 10] transport protocol represented by a bundled "m=" line. [Section 10]
defines additional considerations for RTP based media. [Section 6] defines additional considerations for RTP based media. [Section 6]
defines additional considerations for the usage of the SDP 'bundle- defines additional considerations for the usage of the SDP 'bundle-
only' attribute. [Section 11] defines additional considerations for only' attribute. [Section 11] defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) mechanism the usage of Interactive Connectivity Establishment (ICE) mechanism
[RFC5245]. [RFC5245].
The offerer and answerer MUST follow the rules and restrictions The offerer and answerer MUST follow the rules and restrictions
defined in Section 7 when creating offers and answers. defined in [Section 7] when creating offers and answers.
8.2. Generating the Initial SDP Offer 8.2. Generating the Initial SDP Offer
8.2.1. General 8.2.1. General
When an offerer generates an initial offer, in order to create a When an offerer generates an initial offer, in order to create a
BUNDLE group, it MUST: BUNDLE group, it MUST:
o Assign a unique address to each "m=" line within the offer, o Assign a unique address to each "m=" line within the offer,
following the procedures in [RFC3264]; following the procedures in [RFC3264];
o Assign an SDP 'group:BUNDLE' attribute to the offer; o Assign an SDP 'group:BUNDLE' attribute to the offer;
o Place the SDP 'mid' attribute value [RFC5888] of each bundled "m=" o Place the SDP 'mid' attribute value [RFC5888] of each bundled "m="
line to the SDP 'group:BUNDLE' attribute mid value list; and line to the SDP 'group:BUNDLE' attribute mid value list; and
o Indicate which unique address the offerer wants the answerer to o Indicate which unique address the offerer wants the answerer to
select as the offerer BUNDLE address Section 8.2.2. select as the offerer BUNDLE address [Section 8.2.2].
If the offerer wants to request that the answerer accepts a given If the offerer wants to request that the answerer accepts a given
"m=" line only if the the answerer keeps the "m=" line within the "m=" line only if the the answerer keeps the "m=" line within the
BUNDLE group, the offerer MUST: BUNDLE group, the offerer MUST:
o Assign an SDP 'bundle-only' attribute Section 8.2.2 to the "m=" o Associate an SDP 'bundle-only' attribute [Section 8.2.2] with the
line; and "m=" line; and
o Assign a zero port value to the "m=" line. o Assign a zero port value to the "m=" line.
NOTE: If the offerer assigns a zero port value to an "m=" line, but NOTE: If the offerer assigns a zero port value to an "m=" line, but
does not also assign an SDP 'bundle-only' attribute to the "m=" line, does not also associate an SDP 'bundle-only' attribute with the "m="
it is an indication that the offerer wants to disable the "m=" line line, it is an indication that the offerer wants to disable the "m="
[Section 8.5.5]. line [Section 8.5.5].
[Section 15.1] shows an example of an initial offer. [Section 15.1] shows an example of an initial offer.
8.2.2. Request offerer BUNDLE address selection 8.2.2. Request offerer BUNDLE address selection
In the offer, the address assigned to the "m=" line associated with In the offer, the address assigned to the "m=" line associated with
the offerer suggested BUNDLE mid indicates the address that the the offerer suggested BUNDLE mid indicates the address that the
offerer wants the answer to select as the offerer BUNDLE address offerer wants the answer to select as the offerer BUNDLE address
[Section 8.3.2]. [Section 8.3.2].
skipping to change at page 10, line 46 skipping to change at page 10, line 46
o The answerer MUST NOT include a BUNDLE group in the answer, unless o The answerer MUST NOT include a BUNDLE group in the answer, unless
the offerer requested the BUNDLE group to be created in the the offerer requested the BUNDLE group to be created in the
associated offer; and associated offer; and
o The answerer MUST NOT include an "m=" line within a BUNDLE group, o The answerer MUST NOT include an "m=" line within a BUNDLE group,
unless the offerer requested to "m=" line to be within a BUNDLE unless the offerer requested to "m=" line to be within a BUNDLE
group in the associated offer. group in the associated offer.
If the answer contains a BUNDLE group, the answerer MUST: If the answer contains a BUNDLE group, the answerer MUST:
o Select an Offerer BUNDLE Address Section 8.3.2; and o Select an Offerer BUNDLE Address [Section 8.3.2]; and
o Select an Answerer BUNDLE Address Section 8.3.3; o Select an Answerer BUNDLE Address [Section 8.3.3];
The answerer is allowed to select a new Answerer BUNDLE address each The answerer is allowed to select a new Answerer BUNDLE address each
time it generates an answer to an offer. time it generates an answer to an offer.
If the answerer does not want to keep an "m=" line within a BUNDLE If the answerer does not want to keep an "m=" line within a BUNDLE
group, it MUST: group, it MUST:
o Move the "m=" line out of the BUNDLE group Section 8.3.4; or o Move the "m=" line out of the BUNDLE group [Section 8.3.4]; or
o Reject the "m=" line Section 8.3.5; o Reject the "m=" line [Section 8.3.5];
If a bundled "m=" line in an offer contains an SDP 'bundle-only' If a bundled "m=" line in an offer has an associated SDP 'bundle-
attribute, and if the answerer keeps the "m=" line within the BUNDLE only' attribute, and if the answerer keeps the "m=" line within the
group, the answerer MUST process the "m=" line as any other bundled BUNDLE group, the answerer MUST process the "m=" line as any other
"m=" line in the offer. The answerer MUST NOT assign a 'bundle-only' bundled "m=" line in the offer. The answerer MUST NOT include a
attribute to any "m=" line in an answer (not even if the "m=" line in 'bundle-only' attribute in an answer.
the associated offer contains a 'bundle-only' attribute).
NOTE: If a bundled "m=" line in an offer contains a port zero value, NOTE: If a bundled "m=" line in an offer contains a port zero value,
but the "m=" line does not contain an SDP 'bundle-only' attribute, it but the "m=" line does not contain an SDP 'bundle-only' attribute, it
is an indication that the offerer wants to disable the "m=" line is an indication that the offerer wants to disable the "m=" line
[Section 8.5.5]. [Section 8.5.5].
8.3.2. Answerer Selection of Offerer Bundle Address 8.3.2. Answerer Selection of Offerer Bundle Address
In an offer, the address (unique or shared) assigned to the bundled In an offer, the address (unique or shared) assigned to the bundled
"m=" line associated with the offerer suggested BUNDLE mid indicates "m=" line associated with the offerer suggested BUNDLE mid indicates
skipping to change at page 14, line 41 skipping to change at page 14, line 41
o The offerer wants to move a bundled "m=" line out of the BUNDLE o The offerer wants to move a bundled "m=" line out of the BUNDLE
group [Section 8.5.4]; or group [Section 8.5.4]; or
o The offerer wants to disable the bundled "m=" line o The offerer wants to disable the bundled "m=" line
[Section 8.5.5]. [Section 8.5.5].
In addition, the offerer MUST select an offerer suggested BUNDLE mid In addition, the offerer MUST select an offerer suggested BUNDLE mid
[Section 8.2.2], even if the offerer does not want the answerer to [Section 8.2.2], even if the offerer does not want the answerer to
select a new offerer BUNDLE address. select a new offerer BUNDLE address.
If the offerer assigns an SDP 'bundle-only' to a bundled "m=" line in If the offerer associates an SDP 'bundle-only' attribute with a
the subsequent offer, if MUST assign the offerer BUNDLE address to bundled "m=" line in the subsequent offer, if MUST assign the offerer
the "m=" line. The offerer MUST NOT assign a unique address, or a BUNDLE address to the "m=" line. The offerer MUST NOT assign a
zero port value, to a bundle-only "m=" line in a subsequent offer. unique address, or a zero port value, to a bundle-only "m=" line in a
subsequent offer.
NOTE: The offerer can in assign an SDP 'bundle-only' attribute to a NOTE: The offerer can associate an SDP 'bundle-only' attribute with a
bundled "m=" line in a subsequent offer, even if the offerer did not bundled "m=" line in a subsequent offer, even if the offerer did not
assign a 'bundle-only' attribute to the "m=" line in a previous associate a 'bundle-only' attribute with the same "m=" line in a
offer. previous offer.
8.5.2. Request new offerer BUNDLE address 8.5.2. Request a new offerer BUNDLE address
When an offerer generates an offer, in which it wants the answerer to When an offerer generates an offer, in which it wants the answerer to
select a new offerer BUNDLE address Section 8.2.2, the offerer MUST: select a new offerer BUNDLE address [Section 8.2.2], the offerer
MUST:
o Assign a unique address, which the offerer wants the answerer to o Assign a unique address, which the offerer wants the answerer to
select as the offerer BUNDLE address, to a bundled "m=" line select as the offerer BUNDLE address, to a bundled "m=" line
(added to the BUNDLE group in a previous offer/answer transaction, (added to the BUNDLE group in a previous offer/answer transaction,
or requested to be added to the BUNDLE group in the current or requested to be added to the BUNDLE group in the current
offer); and offer); and
o Indicate that the offerer wants the answerer to select the unique o Indicate that the offerer wants the answerer to select the unique
address as the offerer BUNDLE address [Section 8.2.2] address as the offerer BUNDLE address [Section 8.2.2]
skipping to change at page 15, line 38 skipping to change at page 15, line 39
bundled "m=" line to BUNDLE group, the offerer MUST: bundled "m=" line to BUNDLE group, the offerer MUST:
o Assign a unique address (excluding bundle-only "m=" lines), or the o Assign a unique address (excluding bundle-only "m=" lines), or the
offerer BUNDLE address (selected by the answerer in a previous offerer BUNDLE address (selected by the answerer in a previous
offer/answer transaction), to the "m=" line; offer/answer transaction), to the "m=" line;
o Place the SDP 'mid' attribute value associated with the "m=" line o Place the SDP 'mid' attribute value associated with the "m=" line
in the SDP 'group:BUNDLE' attribute mid list associated with the in the SDP 'group:BUNDLE' attribute mid list associated with the
BUNDLE group [Section 8.2.2]. BUNDLE group [Section 8.2.2].
NOTE: Adding a unique address to the "m=" line allows the answerer to
move the "m=" line out of the BUNDLE group [Section 8.3.4], without
having to reject the "m=" line.
If the offerer wants the answerer to select the address associated If the offerer wants the answerer to select the address associated
with the added "m=" line as the new offerer BUNDLE address, the with the added "m=" line as the new offerer BUNDLE address, the
offerer suggested BUNDLE mid MUST represent the added "m=" line offerer suggested BUNDLE mid MUST represent the added "m=" line
[Section 8.2.2]. [Section 8.2.2].
If the offerer assigns an SDP 'bundle-only' attribute to the added If the offerer associates an SDP 'bundle-only' attribute with the
"m=" line, the offerer MUST assign the offerer BUNDLE address added "m=" line, the offerer MUST assign the offerer BUNDLE address
(selected by the answerer in a previous offer/answer transaction) to (selected by the answerer in a previous offer/answer transaction) to
the "m=" line. the "m=" line.
[Section 15.3] shows an example where an offerer sends an offer in [Section 15.3] shows an example where an offerer sends an offer in
order to add a bundled "m=" line to a BUNDLE group. order to add a bundled "m=" line to a BUNDLE group.
8.5.4. Moving A Media Description Out Of A BUNDLE Group 8.5.4. Moving A Media Description Out Of A BUNDLE Group
When an offerer generates an offer, in which it wants to move a When an offerer generates an offer, in which it wants to move a
bundled "m=" line (added to the BUNDLE group in a previous offer/ bundled "m=" line (added to the BUNDLE group in a previous offer/
answer transaction), the offerer: answer transaction), the offerer:
o MUST assign a unique address to the "m=" line; o MUST assign a unique address to the "m=" line;
o MUST NOT place a mid value associated with the "m=" line in the o MUST NOT place a mid value associated with the "m=" line in the
SDP 'group:BUNDLE' attribute mid list associated with the BUNDLE SDP 'group:BUNDLE' attribute mid list associated with the BUNDLE
group; and group; and
o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" line. o MUST NOT associate an SDP 'bundle-only' attribute with the "m="
line.
[Section 15.4] shows an example of an offer for moving an "m=" line [Section 15.4] shows an example of an offer for moving an "m=" line
out of a BUNDLE group. out of a BUNDLE group.
8.5.5. Disabling A Media Description In A BUNDLE Group 8.5.5. Disabling A Media Description In A BUNDLE Group
When an offerer generates an offer, in which it wants to disable a When an offerer generates an offer, in which it wants to disable a
bundled "m=" line (added to the BUNDLE group in a previous offer/ bundled "m=" line (added to the BUNDLE group in a previous offer/
answer transaction), the offerer: answer transaction), the offerer:
o MUST assign an address with a zero port value to the "m=" line, o MUST assign an address with a zero port value to the "m=" line,
following the procedures in [RFC4566]; following the procedures in [RFC4566];
o MUST NOT place a mid value associated with the "m=" line in the o MUST NOT place a mid value associated with the "m=" line in the
SDP 'group:BUNDLE' attribute mid list associated with the BUNDLE SDP 'group:BUNDLE' attribute mid list associated with the BUNDLE
group; and group; and
o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" line. o MUST NOT associate an SDP 'bundle-only' attribute with the "m="
line.
[Section 15.5] shows an example of an offer for disabling an "m=" [Section 15.5] shows an example of an offer for disabling an "m="
line within a BUNDLE group. line within a BUNDLE group.
9. Protocol Identification 9. Protocol Identification
9.1. General 9.1. General
If bundled "m=" lines represent different transport protocols, there If bundled "m=" lines represent different transport protocols, there
MUST exist a publically available specification which describes a MUST exist a publically available specification which describes a
skipping to change at page 19, line 11 skipping to change at page 19, line 17
information to associate received RTP packets with the correct "m=" information to associate received RTP packets with the correct "m="
line. However, an offerer will not know which SSRC values the line. However, an offerer will not know which SSRC values the
answerer will use until it has received the answer providing that answerer will use until it has received the answer providing that
information. Due to this, before the offerer has received the information. Due to this, before the offerer has received the
answer, the offerer will not be able to associate received RTP/RTCP answer, the offerer will not be able to associate received RTP/RTCP
packets with the correct "m=" line using the SSRC values. packets with the correct "m=" line using the SSRC values.
In order for an offerer and answerer to always be able to associate In order for an offerer and answerer to always be able to associate
received RTP and RTCP packets with the correct "m=" line, an offerer received RTP and RTCP packets with the correct "m=" line, an offerer
and answerer using the BUNDLE extension MUST use the mechanism and answerer using the BUNDLE extension MUST use the mechanism
defined in Section 13, where the remote endpoint inserts the SDP defined in [Section 13], where the remote endpoint inserts the SDP
'mid' attribute value of an "m=" line in RTP and RTCP packets 'mid' attribute value of an "m=" line in RTP and RTCP packets
associated with that "m=" line. associated with that "m=" line.
10.3. RTP/RTCP Multiplexing 10.3. RTP/RTCP Multiplexing
10.3.1. General 10.3.1. General
When a BUNDLE group, which contains RTP based media, is created, the When a BUNDLE group, which contains RTP based media, is created, the
offerer and answerer MUST negotiate whether to enable RTP/RTCP offerer and answerer MUST negotiate whether to enable RTP/RTCP
multiplexing for the RTP based media associated with the BUNDLE group multiplexing for the RTP based media associated with the BUNDLE group
skipping to change at page 20, line 32 skipping to change at page 20, line 36
previous offer/answer transaction, and the offerer indicates that it previous offer/answer transaction, and the offerer indicates that it
wants to continue using RTP/RTCP multiplexing in a subsequent offer, wants to continue using RTP/RTCP multiplexing in a subsequent offer,
the answerer MUST assign an SDP 'rtcp-mux' attribute to each bundled the answerer MUST assign an SDP 'rtcp-mux' attribute to each bundled
"m=" line in the answer. I.e. the answerer MUST NOT disable the "m=" line in the answer. I.e. the answerer MUST NOT disable the
usage of RTP/RTCP multiplexing. usage of RTP/RTCP multiplexing.
10.3.2.4. Offerer Processing of the SDP Answer 10.3.2.4. Offerer Processing of the SDP Answer
When the offerer receives an answer, if the answerer accepts the When the offerer receives an answer, if the answerer accepts the
usage of RTP/RTCP multiplexing, by including an SDP 'rtcp-mux' usage of RTP/RTCP multiplexing, by including an SDP 'rtcp-mux'
attribute to each bundled "m=" line in the answer Section 10.3.2.3, attribute to each bundled "m=" line in the answer [Section 10.3.2.3],
the answerer follows the procedures for RTP/RTCP multiplexing defined the answerer follows the procedures for RTP/RTCP multiplexing defined
in [RFC5245]. in [RFC5245].
If the answerer does not accept the usage of RTP/RTCP multiplexing If the answerer does not accept the usage of RTP/RTCP multiplexing
Section 10.3.2.3, the offerer MUST use separate 5-tuples for RTP and [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP
RTCP. and RTCP.
10.3.2.5. Modifying the Session 10.3.2.5. Modifying the Session
When an offerer generates a subsequent offer, if it wants to When an offerer generates a subsequent offer, if it wants to
negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, or if negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, or if
it wants to continue usage of RTP/RTCP multiplexing (negotiated in a it wants to continue usage of RTP/RTCP multiplexing (negotiated in a
previous offer/answer transaction), it MUST assign SDP 'rtcp-mux' and previous offer/answer transaction), it MUST assign SDP 'rtcp-mux' and
'rtcp' attributes to each bundled "m=" line (including bundle-only 'rtcp' attributes to each bundled "m=" line (including bundle-only
"m=" lines, and a bundled "m=" line that the offerer wants to add to "m=" lines, and a bundled "m=" line that the offerer wants to add to
the BUNDLE group), unless the offerer wants to disable or remove the the BUNDLE group), unless the offerer wants to disable or remove the
skipping to change at page 22, line 9 skipping to change at page 22, line 9
previously selected BUNDLE address) to one or more bundled "m=" line previously selected BUNDLE address) to one or more bundled "m=" line
(including bundle-only "m=" lines), and when it assigns an address (including bundle-only "m=" lines), and when it assigns an address
with a zero port value to one or more bundle-only "m=" lines, it MUST with a zero port value to one or more bundle-only "m=" lines, it MUST
assign identical ICE candidates (referred to as shared ICE assign identical ICE candidates (referred to as shared ICE
candidates) to each of those "m=" lines. candidates) to each of those "m=" lines.
11.2.2. Generating the Initial SDP Offer 11.2.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, it assigns unique or When an offerer generates an initial offer, it assigns unique or
shared ICE candidates to the bundled "m=" lines, according to shared ICE candidates to the bundled "m=" lines, according to
Section 11.1. [Section 11.1].
11.2.3. Generating the SDP Answer 11.2.3. Generating the SDP Answer
When an answerer generates an answer, which contains a BUNDLE group, When an answerer generates an answer, which contains a BUNDLE group,
the answerer MUST assign shared ICE candidates to each bundled "m=" the answerer MUST assign shared ICE candidates to each bundled "m="
line (including "m=" lines that were indicated as bundle-only in the line (including "m=" lines that were indicated as bundle-only in the
associated offer) in the answer. associated offer) in the answer.
11.2.4. Offerer Processing of the SDP Answer 11.2.4. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer supports and uses When an offerer receives an answer, if the answerer supports and uses
the ICE mechanism and the BUNDLE extension, the offerer MUST assign the ICE mechanism and the BUNDLE extension, the offerer MUST assign
the ICE candidates, associated with the "m=" line representing the the ICE candidates, associated with the "m=" line representing the
offerer BUNDLE address (selected by the answerer) to each bundled offerer BUNDLE address (selected by the answerer) to each bundled
"m=" line. "m=" line.
11.2.5. Modifying the Session 11.2.5. Modifying the Session
When an offerer generates a subsequent offer, it assigns unique or When an offerer generates a subsequent offer, it assigns unique or
shared ICE candidates to the bundled "m=" lines, according to shared ICE candidates to the bundled "m=" lines, according to
Section 11.1. [Section 11.1].
12. Update to RFC 3264 12. Update to RFC 3264
12.1. General 12.1. General
This section replaces the text of the following sections of RFC 3264: This section replaces the text of the following sections of RFC 3264:
o Section 5.1 (Unicast Streams). o Section 5.1 (Unicast Streams).
o Section 8.2 (Removing a Media Stream). o Section 8.2 (Removing a Media Stream).
skipping to change at page 26, line 27 skipping to change at page 26, line 27
Extensions subregistry of the Real-Time Transport Protocol (RTP) Extensions subregistry of the Real-Time Transport Protocol (RTP)
Parameters registry, according to the following data: Parameters registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid
Description: Media identification Description: Media identification
Contact: christer.holmberg@ericsson.com Contact: christer.holmberg@ericsson.com
Reference: RFCXXXX Reference: RFCXXXX
14. Security Considerations 14. Security Considerations
This specification does not significantly change the security The security considerations defined in [RFC3264] and [RFC5888] apply
considerations of SDP which can be found in Section X of TBD. to the BUNDLE extension.
TODO: Think carefully about security analysis of reuse of same SDES When the BUNDLE extension is used the a single set of security
key on multiple "m=" lines when the far end does not use BUNDLE and credentials might be used for all media streams associated with a
warn developers of any risks. BUNDLE group. If the security credentials are compromised, an
attacker will have access to all media content.
15. Examples 15. Examples
15.1. Example: Bundle Address Selection 15.1. Example: Bundle Address Selection
The example below shows: The example below shows:
o 1. An offer, in which the offerer assigns a unique address to o 1. An offer, in which the offerer assigns a unique address to
each bundled "m=" line within the BUNDLE group. each bundled "m=" line within the BUNDLE group.
skipping to change at page 35, line 30 skipping to change at page 35, line 30
Alvestrand proposal. Alvestrand proposal.
Thanks to Paul Kyzivat, Martin Thompson and Flemming Andreasen for Thanks to Paul Kyzivat, Martin Thompson and Flemming Andreasen for
taking the time to read the text along the way, and providing useful taking the time to read the text along the way, and providing useful
feedback. feedback.
18. Change Log 18. 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-09
o Terminology change: "bundle-only attribute assigned to m= line" to
"bundle-only attribute associated with m= line".
o Editorial corrections.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08
o Editorial corrections. o Editorial corrections.
o - "of"->"if" (8.3.2.5). o - "of"->"if" (8.3.2.5).
o - "optional"->"OPTIONAL" (9.1). o - "optional"->"OPTIONAL" (9.1).
o - Syntax/ABNF for 'bundle-only' attribute added. o - Syntax/ABNF for 'bundle-only' attribute added.
 End of changes. 43 change blocks. 
77 lines changed or deleted 93 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/