draft-ietf-mmusic-sdp-bundle-negotiation-13.txt   draft-ietf-mmusic-sdp-bundle-negotiation-14.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: June 11, 2015 C. Jennings Expires: June 22, 2015 C. Jennings
Cisco Cisco
December 8, 2014 December 19, 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-13.txt draft-ietf-mmusic-sdp-bundle-negotiation-14.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single address:port combination (BUNDLE address) for receiving media, single address:port combination (BUNDLE address) for receiving media,
referred to as bundled media, associated with multiple SDP media referred to as bundled media, associated with multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 June 11, 2015. This Internet-Draft will expire on June 22, 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 3, line 10 skipping to change at page 3, line 10
8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11
8.3.2. Answerer Selection of Offerer Bundle Address . . . . 12 8.3.2. Answerer Selection of Offerer Bundle Address . . . . 12
8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 13 8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 13
8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 13 8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 13
8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 13 8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 13
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14
8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 14 8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 14
8.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 14 8.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 14
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 15 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 15
8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 15 8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 15
8.5.2. Request a new offerer BUNDLE address . . . . . . . . 15 8.5.2. Suggesting a new offerer BUNDLE address . . . . . . . 15
8.5.3. Adding a media description to a BUNDLE group . . . . 16 8.5.3. Adding a media description to a BUNDLE group . . . . 16
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 . . 17
8.5.5. Disabling A Media Description In A BUNDLE Group . . . 17 8.5.5. Disabling A Media Description In A BUNDLE Group . . . 17
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 17 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 17
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 18
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18
10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18
10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 19 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 19
10.2. Associating RTP/RTCP Packets With Correct SDP Media 10.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 19 Description . . . . . . . . . . . . . . . . . . . . . . 19
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 20 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 20
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23
11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23
11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24
11.2.5. Modifying the Session . . . . . . . . . . . . . . . 23 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24
12. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24 12. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24
12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24
12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 24 12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 24
12.3. New text replacing section 5.1 (2nd paragraph) of RFC 12.3. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25 12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25
12.5. New text replacing section 8.2 (2nd paragraph) of RFC 12.5. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 25 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 25
12.7. New text replacing section 8.4 (6th paragraph) of RFC 12.7. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13. RTP/RTCP extensions for identification-tag transport . . . . 26 13. RTP/RTCP extensions for identification-tag transport . . . . 26
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26
13.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27 13.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27
13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 27 13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 27
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 27 14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28
14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 28 14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 28
14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 28 14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 28
15. Security Considerations . . . . . . . . . . . . . . . . . . . 28 15. Security Considerations . . . . . . . . . . . . . . . . . . . 29
16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29 16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29
16.1. Example: Bundle Address Selection . . . . . . . . . . . 29 16.1. Example: Bundle Address Selection . . . . . . . . . . . 29
16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 31 16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 31
16.3. Example: Offerer Adds A Media Description To A BUNDLE 16.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 32 Group . . . . . . . . . . . . . . . . . . . . . . . . . 32
16.4. Example: Offerer Moves A Media Description Out Of A 16.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35
16.5. Example: Offerer Disables A Media Description Within A 16.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
19.1. Normative References . . . . . . . . . . . . . . . . . . 42 19.1. Normative References . . . . . . . . . . . . . . . . . . 42
19.2. Informative References . . . . . . . . . . . . . . . . . 43 19.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Design Considerations . . . . . . . . . . . . . . . 43 Appendix A. Design Considerations . . . . . . . . . . . . . . . 44
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 43 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 44 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 44
A.3. Usage of port number value zero . . . . . . . . . . . . . 46 A.3. Usage of port number value zero . . . . . . . . . . . . . 46
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 46 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 46
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 47 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 47
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 47 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 47
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 47 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
skipping to change at page 6, line 35 skipping to change at page 6, line 35
Bundle-only "m=" line: A bundled "m=" line with an associated SDP Bundle-only "m=" line: A bundled "m=" line with an associated SDP
'bundle-only' attribute. '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 offer/answer exchange.
Identification-tag: A unique token value that is used to identify an Identification-tag: A unique token value that is used to identify an
"m=" line. The SDP 'mid' attribute [RFC5888], associated with an "m=" line. The SDP 'mid' attribute [RFC5888], associated with an
"m=" line, carries an unique identification-tag. The session-level "m=" line, carries an unique identification-tag. The session-level
SDP 'group' attribute [RFC5888] carries a list of identification- SDP 'group' attribute [RFC5888] carries a list of identification-
tags, identifying the "m=" lines associated with that particular tags, identifying the "m=" lines associated with that particular
'group' attribute. 'group' attribute.
3. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
4. Applicability Statement 4. Applicability Statement
The mechanism in this specification only applies to the Session The mechanism in this specification only applies to the Session
Description Protocol (SDP) [RFC4566], when used together with the SDP Description Protocol (SDP) [RFC4566], when used together with the SDP
Offer/Answer mechanism [RFC3264]. offer/answer mechanism [RFC3264].
5. SDP Grouping Framework BUNDLE Extension 5. SDP Grouping Framework BUNDLE Extension
5.1. General 5.1. General
This section defines a new SDP Grouping Framework extension This section defines a new SDP Grouping Framework extension
[RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the SDP [RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the SDP
Offer/Answer mechanism to negotiate the usage of a single Offer/Answer mechanism to negotiate the usage of a single
address:port combination (BUNDLE address) for receiving bundled address:port combination (BUNDLE address) for receiving bundled
media. media.
skipping to change at page 10, line 24 skipping to change at page 10, line 24
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) [RFC5245] the usage of Interactive Connectivity Establishment (ICE) [RFC5245]
mechanism . mechanism .
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.
SDP bodies can contain multiple BUNDLE groups. The procedures in SDP offers and answers can contain multiple BUNDLE groups. The
this section apply independently to a given BUNDLE group. procedures in this section apply independently to a given BUNDLE
group.
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];
skipping to change at page 10, line 49 skipping to change at page 10, line 50
o Add an SDP 'group:BUNDLE' attribute to the offer; o Add an SDP 'group:BUNDLE' attribute to the offer;
o Place the identification-tag of each bundled "m=" line in the SDP o Place the identification-tag of each bundled "m=" line in the SDP
'group:BUNDLE' attribute identification-tag list; and 'group:BUNDLE' attribute identification-tag list; and
o Indicate which unique address the offerer suggests as the offerer o Indicate which unique address the offerer suggests as the offerer
BUNDLE address [Section 8.2.2]. 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 answerer keeps the "m=" line within the BUNDLE bundled "m=" line only if the answerer keeps the "m=" line within the
group, the offerer MUST: BUNDLE group, the offerer MUST:
o Associate an SDP 'bundle-only' attribute [Section 8.2.2] with the o Associate an SDP 'bundle-only' attribute [Section 8.2.2] with the
"m=" 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 associate an SDP 'bundle-only' attribute with the "m=" does not also associate an SDP 'bundle-only' attribute with the "m="
line, it is an indication that the offerer wants to disable the "m=" line, it is an indication that the offerer wants to disable the "m="
line [Section 8.5.5]. line [Section 8.5.5].
skipping to change at page 12, line 48 skipping to change at page 12, line 48
the address associated with the "m=" line as the offerer BUNDLE the address associated with the "m=" line as the offerer BUNDLE
address. In the answer, the answerer BUNDLE-tag represents the "m=" address. In the answer, the answerer BUNDLE-tag represents the "m="
line, and the address associated with the "m=" line in the offer line, and the address associated with the "m=" line in the offer
becomes the offerer BUNDLE address. becomes the offerer BUNDLE address.
If one or more of the criteria are not fulfilled, the answerer MUST If one or more of the criteria are not fulfilled, the answerer MUST
select the next identification-tag in the identification-tag list, select the next identification-tag in the identification-tag list,
and perform the same criteria check for the "m=" line associated with and perform the same criteria check for the "m=" line associated with
that identification-tag. If there are no more identification-tags in that identification-tag. If there are no more identification-tags in
the identification-tag list, the answerer MUST NOT create the BUNDLE the identification-tag list, the answerer MUST NOT create the BUNDLE
group. group. In addition, unless the answerer rejects the whole offer, the
answerer MUST apply the answerer procedures for moving an "m=" line
out of a BUNDLE group [Section 8.3.4] to each bundled "m=" line in
the offer when creating the answer.
[Section 16.1] shows an example of an offerer BUNDLE address [Section 16.1] shows an example of an offerer BUNDLE address
selection. selection.
8.3.3. Answerer Selection of Answerer BUNDLE Address 8.3.3. Answerer Selection of Answerer BUNDLE Address
When the answerer selects a BUNDLE address for itself, referred to as When the answerer selects a BUNDLE address for itself, referred to as
the answerer BUNDLE address, it MUST assign that address to each the answerer BUNDLE address, it MUST assign that address to each
bundled "m=" line within the created BUNDLE group in the answer. bundled "m=" line within the created BUNDLE group in the answer.
skipping to change at page 14, line 29 skipping to change at page 14, line 33
If the answer does not contain a BUNDLE group, the offerer MUST If the answer does not contain a BUNDLE group, the offerer MUST
process the answer as a normal answer. process the answer as a normal answer.
8.4.2. Bundle Address Synchronization (BAS) 8.4.2. Bundle Address Synchronization (BAS)
When an offerer receives an answer, if the answer contains a BUNDLE When an offerer receives an answer, if the answer contains a BUNDLE
group, the offerer MUST check whether the offerer BUNDLE address, group, the offerer MUST check whether the offerer BUNDLE address,
selected by the answerer [Section 8.3.2], matches what was assigned selected by the answerer [Section 8.3.2], matches what was assigned
to each bundled "m=" line (excluding any bundled "m=" line that was to each bundled "m=" line (excluding any bundled "m=" line that was
rejected, or moved out of the BUNDLE group, by the answer) in the rejected, or moved out of the BUNDLE group, by the answerer) in the
associated offer. If there is a mismatch, the offerer SHOULD as soon associated offer. If there is a mismatch, the offerer SHOULD as soon
as possible generate a subsequent offer, in which it assigns the as possible generate a subsequent offer, in which it assigns the
offerer BUNDLE address to each bundled "m=" line. Such offer is offerer BUNDLE address to each bundled "m=" line. Such offer is
referred to as a Bundle Address Synchronization (BAS) offer. referred to as a Bundle Address Synchronization (BAS) offer.
A BAS offer is typically sent in the following scenarios: A BAS offer is typically sent in the following scenarios:
o The offerer receives an answer to an initial offer, as the bundled o The offerer receives an answer to an initial offer, as the bundled
"m=" lines in the initial offer always contain unique addresses "m=" lines in the initial offer always contain unique addresses
[Section 8.2]; or [Section 8.2]; or
skipping to change at page 15, line 37 skipping to change at page 15, line 42
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 BUNDLE-tag In addition, the offerer MUST select an offerer BUNDLE-tag
[Section 8.2.2], even if the offerer does not suggest a new offerer [Section 8.2.2], even if the offerer does not suggest a new offerer
BUNDLE address. BUNDLE address.
The offerer MUST NOT associate an SDP 'bundle-only' attribute with a 8.5.2. Suggesting a new offerer BUNDLE address
bundled "m=" line in a subsequent offer, unless the offerer also
assigns a zero port value to the "m=" line.
8.5.2. Request a new offerer BUNDLE address
When an offerer generates an offer, in which it suggests a new When an offerer generates an offer, in which it suggests a new
offerer BUNDLE address [Section 8.2.2], the offerer MUST: offerer BUNDLE address [Section 8.2.2], the offerer MUST:
o Assign a unique address, which the offerer suggests as the new o Assign the address (shared address) to each "m=" line within the
offerer BUNDLE address, to a bundled "m=" line; and BUNDLE group; or
o Indicate that the offerer suggests the unique address as the new o Assign the address (unique address) to one bundled "m=" line.
offerer BUNDLE address [Section 8.2.2]
NOTE: The offerer can assign a unique address to each bundled "m=" In addition, the offerer MUST indicate that the offerer suggests
line in the offer, or it can assign the previously selected offerer address as the new offerer BUNDLE address [Section 8.2.2]
BUNDLE address to each "m=" line (except to the "m=" line to which it
assigns the unique address that it suggests as the new offerer BUNDLE NOTE: Unless the offerer assigns the new suggested offerer BUNDLE
address). address to each bundled "m=" line, it can assign unique addresses to
any number of bundled "m=" lines (and the previously selected offerer
BUNDLE address to any remaining bundled "m=" line) if it wants to
suggest multiple alternatives for the new offerer BUNDLE address.
8.5.3. Adding a media description to a BUNDLE group 8.5.3. Adding a media description to a BUNDLE group
When an offerer generates an offer, in which it wants to add a When an offerer generates an offer, in which it wants to add a
bundled "m=" line to a BUNDLE group, the offerer MUST: bundled "m=" line to a BUNDLE group, the offerer MUST:
o Assign a unique address, or the previously selected offerer BUNDLE o Assign a unique address to the "m=" line;
address, to the "m=" line; and
o Extend the SDP 'group:BUNDLE' attribute identification-tag list o Assign the previously selected offerer BUNDLE address to the "m="
with the BUNDLE group [Section 8.2.2] by adding the line; or
identification-tag associated with the added "m=" line to the
list. o If the offerer assigns a new suggested offerer BUNDLE address to
each bundled "m=" line [Section 8.5.2], also assign that address
to the added "m=" line.
In addition, the offerer MUST extend the SDP 'group:BUNDLE' attribute
identification-tag list with the BUNDLE group [Section 8.2.2] by
adding the identification-tag associated with the added "m=" line to
the list.
NOTE: Assigning a unique address to the "m=" line allows the answerer NOTE: Assigning a unique address to the "m=" line allows the answerer
to move the "m=" line out of the BUNDLE group [Section 8.3.4], to move the "m=" line out of the BUNDLE group [Section 8.3.4],
without having to reject the "m=" line. without having to reject the "m=" line.
If the offerer suggests the address associated with the added "m=" If the offerer assigns a unique address to the added "m=" line, and
line as the new offerer BUNDLE address, the offerer BUNDLE-tag MUST if the offerer suggests that address as the new offerer BUNDLE
represent the added "m=" line [Section 8.2.2]. address [Section 8.5.2], the offerer BUNDLE-tag MUST represent the
added "m=" line [Section 8.2.2].
If the offerer assigns a new suggested offerer BUNDLE address to each
bundled "m=" line [Section 8.5.2], including the added "m=" line, the
offerer BUNDLE-tag MAY represent the added "m=" line [Section 8.2.2].
[Section 16.3] shows an example where an offerer sends an offer in [Section 16.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 out of a BUNDLE group it was added to in a previous bundled "m=" line out of a BUNDLE group it was added to in a previous
offer/answer transaction, the offerer: offer/answer transaction, the offerer:
skipping to change at page 23, line 4 skipping to change at page 23, line 17
o When BUNDLE addresses for a BUNDLE group have been selected for o When BUNDLE addresses for a BUNDLE group have been selected for
both endpoints, ICE connectivity checks and keep-alives only need both endpoints, ICE connectivity checks and keep-alives only need
to be performed for the whole BUNDLE group, instead of per bundled to be performed for the whole BUNDLE group, instead of per bundled
"m=" line. "m=" line.
Support and usage of ICE mechanism together with the BUNDLE extension Support and usage of ICE mechanism together with the BUNDLE extension
is OPTIONAL. is OPTIONAL.
11.2. SDP Offer/Answer Procedures 11.2. SDP Offer/Answer Procedures
11.2.1. General 11.2.1. General
When an offerer assigns a unique address to a bundled "m=" line When an offerer assigns a unique address to a bundled "m=" line
(excluding and bundle-only "m=" line), it MUST also associate unique (excluding any bundle-only "m=" line), it MUST also associate unique
ICE candidates [RFC5245] to the "m=" line. ICE candidates [RFC5245] to the "m=" line.
An offerer MUST NOT assign ICE candidates to a bundle-only "m=" line An offerer MUST NOT assign ICE candidates to a bundle-only "m=" line
with a zero port value. with a zero port value.
NOTE: The bundle-only "m=" line, if accepted by the answerer, will NOTE: The bundle-only "m=" line, if accepted by the answerer, will
inherit the candidates associated with the selected offerer BUNDLE inherit the candidates associated with the selected offerer BUNDLE
address. An answerer that does not support BUNDLE would not accept a address. An answerer that does not support BUNDLE would not accept a
bundle-only "m=" line. bundle-only "m=" line.
skipping to change at page 38, line 16 skipping to change at page 38, line 16
Alvestrand proposal. Alvestrand proposal.
Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas
Stach and Ari Keraenen for taking the time to read the text along the Stach and Ari Keraenen for taking the time to read the text along the
way, and providing useful feedback. way, and providing useful 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-13
o Changes to allow a new suggested offerer BUNDLE address to be
assigned to each bundled m- line.
o Changes based on WGLC comments from Paul Kyzivat
o - Editorial fixes
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12
o Usage of SDP 'extmap' attribute added o Usage of SDP 'extmap' attribute added
o SDP 'bundle-only' attribute scoped with "m=" lines with a zero o SDP 'bundle-only' attribute scoped with "m=" lines with a zero
port value port value
o Changes based on WGLC comments from Thomas Stach o Changes based on WGLC comments from Thomas Stach
o - ICE candidates not assigned to bundle-only m- lines with a zero o - ICE candidates not assigned to bundle-only m- lines with a zero
 End of changes. 30 change blocks. 
49 lines changed or deleted 72 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/