draft-ietf-mmusic-sdp-bundle-negotiation-40.txt   draft-ietf-mmusic-sdp-bundle-negotiation-41.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: May 24, 2018 C. Jennings Expires: May 31, 2018 C. Jennings
Cisco Cisco
November 20, 2017 November 27, 2017
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-40.txt draft-ietf-mmusic-sdp-bundle-negotiation-41.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 transport (5-tuple) for sending and receiving media described single transport (5-tuple) for sending and receiving media described
by multiple SDP media descriptions ("m=" sections). Such transport by multiple SDP media descriptions ("m=" sections). Such transport
is referred to as a BUNDLE transport, and the media is referred to as is referred to as a BUNDLE transport, and the media is referred to as
bundled media. The "m=" sections that use the BUNDLE transport form bundled media. The "m=" sections that use the BUNDLE transport form
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 May 24, 2018. This Internet-Draft will expire on May 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 11 skipping to change at page 3, line 11
8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9
8.1. Mux Category Considerations . . . . . . . . . . . . . . . 10 8.1. Mux Category Considerations . . . . . . . . . . . . . . . 10
8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11
8.2.1. Suggesting the offerer BUNDLE address . . . . . . . . 11 8.2.1. Suggesting the offerer BUNDLE address . . . . . . . . 11
8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12 8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 12 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 12
8.3.1. Answerer Selection of Offerer Bundle Address . . . . 13 8.3.1. Answerer Selection of Offerer Bundle Address . . . . 13
8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 14 8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 14
8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 14 8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 14
8.3.4. Rejecting A Media Description In A BUNDLE Group . . . 15 8.3.4. Rejecting A Media Description In A BUNDLE Group . . . 15
8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 15 8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 16
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 16 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 16
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 16 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 17
8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 17 8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 17
8.5.2. Adding a media description to a BUNDLE group . . . . 17 8.5.2. Adding a media description to a BUNDLE group . . . . 17
8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 18 8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 18
8.5.4. Disabling A Media Description In A BUNDLE Group . . . 19 8.5.4. Disabling A Media Description In A BUNDLE Group . . . 19
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 19 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 19
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 20 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 20
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 21 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 21
10.2. Associating RTP/RTCP Streams With Correct SDP Media 10.2. Associating RTP/RTCP Streams With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 21 Description . . . . . . . . . . . . . . . . . . . . . . 21
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 27 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 27
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 27 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 27
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 29
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 30 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 30
11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 31
11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 31
11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 31
11.1.4. Modifying the Session . . . . . . . . . . . . . . . 31
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 31 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 31
13. RTP Header Extensions Consideration . . . . . . . . . . . . . 32 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 31
14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 32 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 32
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 32 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 32
14.2. New text replacing section 5.1 (2nd paragraph) of RFC 14.2. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 33 14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 33
14.4. New text replacing section 8.2 (2nd paragraph) of RFC 14.4. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 33 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 33
14.6. New text replacing section 8.4 (6th paragraph) of RFC 14.6. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
15. RTP/RTCP extensions for identification-tag transport . . . . 34 15. RTP/RTCP extensions for identification-tag transport . . . . 34
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 35 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 35
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 35 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 35
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 36 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 36
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 36 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 36
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 37 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 37
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 37 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 37
17. Security Considerations . . . . . . . . . . . . . . . . . . . 38 17. Security Considerations . . . . . . . . . . . . . . . . . . . 37
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39
18.1. Example: Bundle Address Selection . . . . . . . . . . . 39 18.1. Example: Bundle Address Selection . . . . . . . . . . . 39
18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 41 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 41
18.3. Example: Offerer Adds A Media Description To A BUNDLE 18.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 42 Group . . . . . . . . . . . . . . . . . . . . . . . . . 42
18.4. Example: Offerer Moves A Media Description Out Of A 18.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 44 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 44
18.5. Example: Offerer Disables A Media Description Within A 18.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 48 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 48
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
21.1. Normative References . . . . . . . . . . . . . . . . . . 57 21.1. Normative References . . . . . . . . . . . . . . . . . . 58
21.2. Informative References . . . . . . . . . . . . . . . . . 59 21.2. Informative References . . . . . . . . . . . . . . . . . 60
Appendix A. Design Considerations . . . . . . . . . . . . . . . 60 Appendix A. Design Considerations . . . . . . . . . . . . . . . 61
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 61 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 61
A.2. Usage of port number value zero . . . . . . . . . . . . . 62 A.2. Usage of port number value zero . . . . . . . . . . . . . 63
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 62 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 63
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 63 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 64
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 63 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 64
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 63 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
1. Introduction 1. Introduction
When multimedia communications are established, each transport When multimedia communications are established, each transport
(5-tuple) reserved for an individual media stream consume additional (5-tuple) reserved for an individual media stream consume additional
resources (especially when Interactive Connectivity Establishment resources (especially when Interactive Connectivity Establishment
(ICE) [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is (ICE) [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is
attractive to use a single transport for multiple media streams. attractive to use a single transport for multiple media streams.
This specification defines a way to use a single transport (BUNDLE This specification defines a way to use a single transport (BUNDLE
skipping to change at page 6, line 22 skipping to change at page 6, line 20
"m=" line. An local address:port combination is assigned to each "m=" line. An local address:port combination is assigned to each
"m=" section. "m=" section.
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 transport-layer port, destination address, destination port, and transport-layer
protocol. protocol.
Unique address: An address:port combination that is assigned to only Unique address: An address:port combination that is assigned to only
one "m=" section in an offer or answer. one "m=" section in an offer or answer.
Shared address: An address:port combination that is assigned to
multiple "m=" sections within an offer or answer.
Offerer BUNDLE-tag: The first identification-tag in a given SDP Offerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an offer. 'group:BUNDLE' attribute identification-tag list in an offer.
Answerer BUNDLE-tag: The first identification-tag in a given SDP Answerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an answer. 'group:BUNDLE' attribute identification-tag list in an answer.
Offerer BUNDLE address: Within a given BUNDLE group, an address:port BUNDLE address: An address:port combination that an endpoint uses for
combination used by an offerer to receive all media described by each sending and receiving bundled media.
"m=" section within the BUNDLE group.
Answerer BUNDLE address: Within a given BUNDLE group, an address:port Offerer BUNDLE address: In an offer, the BUNDLE address of the
combination used by an answerer to receive all media described by offerer.
each "m=" section within the BUNDLE group.
Answerer BUNDLE address: In an answer, the BUNDLE address of the
answerer.
BUNDLE transport: The transport (5-tuple) used by all media described BUNDLE transport: The transport (5-tuple) used by all media described
by the "m=" sections within a BUNDLE group. by the "m=" sections within a BUNDLE group.
BUNDLE group: A set of "m=" sections, created using an SDP Offer/ BUNDLE group: A set of "m=" sections, created using an SDP Offer/
Answer exchange, which uses a single BUNDLE transport for sending and Answer exchange, which uses a single BUNDLE transport for sending and
receiving all media described by the set of "m=" sections. The same receiving all media (bundled media) described by the set of "m="
BUNDLE transport is used for sending and receiving media. sections. The same BUNDLE transport is used for sending and
receiving bundled media.
Bundled "m=" section: An "m=" section, whose identification-tag is Bundled "m=" section: An "m=" section, whose identification-tag is
placed in an SDP 'group:BUNDLE' attribute identification-tag list in placed in an SDP 'group:BUNDLE' attribute identification-tag list in
an offer or answer. an offer or answer.
Bundle-only "m=" section: A bundled "m=" section that contains an SDP Bundle-only "m=" section: A bundled "m=" section that contains an SDP
'bundle-only' attribute. 'bundle-only' attribute.
Bundled media: All media specified by a given BUNDLE group. Bundled media: All media associated with a given BUNDLE group.
Initial offer: The first offer, within an SDP session (e.g. a SIP Initial offer: The first offer, within an SDP session (e.g. a SIP
dialog when the Session Initiation Protocol (SIP) [RFC3261] is used dialog when the Session Initiation Protocol (SIP) [RFC3261] is used
to carry SDP), in which the offerer indicates that it wants to create to carry SDP), in which the offerer indicates that it wants to create
a given BUNDLE group. 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 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
skipping to change at page 8, line 46 skipping to change at page 8, line 43
In order to ensure that an answerer that does not support the BUNDLE In order to ensure that an answerer that does not support the BUNDLE
extension always rejects a bundled "m=" section, the offerer can extension always rejects a bundled "m=" section, the offerer can
assign a zero port value to the "m=" section. According to [RFC3264] assign a zero port value to the "m=" section. According to [RFC3264]
an answerer will reject such "m=" section. By including an SDP an answerer will reject such "m=" section. By including an SDP
'bundle-only' attribute in such "m=" section, the offerer can request 'bundle-only' attribute in such "m=" section, the offerer can request
that the answerer accepts the "m=" section if the answerer supports that the answerer accepts the "m=" section if the answerer supports
the Bundle extension, and if the answerer keeps the "m=" section the Bundle extension, and if the answerer keeps the "m=" section
within the associated BUNDLE group. within the associated BUNDLE group.
NOTE: Once the offerer BUNDLE address has been selected, the offerer Once the offerer and answerer BUNDLE addresses have been selected, an
does not need to include the 'bundle-only' attribute in subsequent offerer and answerer only assigns the BUNDLE address to one bundled
offers. By assigning the offerer BUNDLE address to an "m=" section "m=" section. To every other bundled "m=" section the offerer and
of a subsequent offer, the offerer will ensure that the answerer will answerer assigns a zero port value and includes an SDP 'bundle-only'
either keep the "m=" section within the BUNDLE group, or the answerer attribute.
will have to reject the "m=" section.
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=" section with a zero port value, within an offer. Other bundled "m=" section with a zero port value, within an offer or
usage is unspecified. answer. 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.
7. SDP Information Considerations 7. SDP Information Considerations
This section describes restrictions associated with the usage of SDP This section describes restrictions associated with the usage of SDP
parameters within a BUNDLE group. It also describes, when parameter parameters within a BUNDLE group. It also describes, when parameter
and attribute values have been assigned to each bundled "m=" section, and attribute values have been assigned to each bundled "m=" section,
how to calculate a value for the whole BUNDLE group. how to calculate a value for the whole BUNDLE group.
skipping to change at page 9, line 44 skipping to change at page 9, line 42
7.2. Bandwidth (b=) 7.2. Bandwidth (b=)
An offerer and answerer MUST use the rules and restrictions defined An offerer and answerer MUST use the rules and restrictions defined
in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP
bandwidth (b=) line with bundled "m=" section. bandwidth (b=) line with bundled "m=" section.
8. SDP Offer/Answer Procedures 8. SDP Offer/Answer Procedures
This section describes the SDP Offer/Answer [RFC3264] procedures for: This section describes the SDP Offer/Answer [RFC3264] procedures for:
o Negotiating and creating a BUNDLE group; and o Negotiating a BUNDLE group; and
o Selecting the BUNDLE addresses (offerer BUNDLE address and o Selecting the BUNDLE addresses (offerer BUNDLE address and
answerer BUNDLE address); and answerer BUNDLE address); and
o Adding an "m=" section to a BUNDLE group; and o Adding an "m=" section to a BUNDLE group; and
o Moving an "m=" section out of a BUNDLE group; and o Moving an "m=" section out of a BUNDLE group; and
o Disabling an "m=" section within a BUNDLE group. o Disabling an "m=" section within a BUNDLE group.
The generic rules and procedures defined in [RFC3264] and [RFC5888] The generic rules and procedures defined in [RFC3264] and [RFC5888]
also apply to the BUNDLE extension. For example, if an offer is also apply to the BUNDLE extension. For example, if an offer is
rejected by the answerer, the previously negotiated SDP parameters rejected by the answerer, the previously negotiated SDP parameters
and characteristics (including those associated with a BUNDLE group) and characteristics (including those associated with a BUNDLE group)
apply. Hence, if an offerer generates an offer in which the offerer apply. Hence, if an offerer generates an offer in which the offerer
wants to create a BUNDLE group, and the answerer rejects the offer, wants to create a BUNDLE group, and the answerer rejects the offer,
the BUNDLE group is not created. the BUNDLE group is not created.
skipping to change at page 10, line 28 skipping to change at page 10, line 27
only' attribute. Section 11 defines additional considerations for only' attribute. Section 11 defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) the usage of Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] mechanism. [I-D.ietf-ice-rfc5245bis] mechanism.
SDP offers and answers can contain multiple BUNDLE groups. The SDP offers and answers can contain multiple BUNDLE groups. The
procedures in this section apply independently to a given BUNDLE procedures in this section apply independently to a given BUNDLE
group. group.
8.1. Mux Category Considerations 8.1. Mux Category Considerations
When an offerer or answerer includes SDP attributes in a bundled "m=" When a BUNDLE group is initially negotiated, and a unique address is
section (including any bundle-only "m=" section) to which a shared assigned to each bundled "m=" section (excluding any bundle-only "m="
address has been assigned, IDENTICAL and TRANSPORT mux category SDP section) in the initial offer Section 8.2, IDENTICAL and TRANSPORT
attributes [I-D.ietf-mmusic-sdp-mux-attributes] are included in the mux category SDP attributes MUST explicitly included in each bundled
"m=" section only if the "m=" section is also associated with the "m=" section (excluding any bundle-only "m=" secctions).
offerer/answerer BUNDLE-tag. Otherwise the offerer/answerer MUST NOT
include such SDP attributes in the "m=" section. The rule above does
not apply to a bundled "m=" section to which a unique address has
been assigned.
NOTE: As bundled "m=" section (including any bundle-only "m=" When an offerer or answerer includes SDP attributes in bundled "m="
section) to which a shared address has been assigned will share the sections within a BUNDLE group for which the offerer and answerer
same IDENTICAL and TRANSPORT mux category SDP attributes, and BUNDLE addresses have been selected, IDENTICAL and TRANSPORT mux
attribute values, there is no need to include such SDP attributes in category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are only
each "m=" section. The attributes and attribute values are included in the "m=" section represented by the BUNDLE-tag in the
implicitly included and applied to each "m=" section. offer or answer. The SDP attribute values are implicitly applied to
each bundled "m=" section (including any bundle-only "m=" section).
The offerer and answerer MUST NOT include such SDP attributes in any
other bundled "m=" section.
The semantics of some SDP attributes only apply to specific types of The semantics of some SDP attributes only apply to specific types of
media. For example, the semantics of the SDP 'rtcp-mux' and SDP media. For example, the semantics of the SDP 'rtcp-mux' and SDP
'rtcp-mux-only' attributes only apply to "m=" sections describing 'rtcp-mux-only' attributes only apply to "m=" sections describing
RTP-based media. However, as described in Section 8.1, there are RTP-based media. However, as described in Section 8.1, there are
cases where IDENTICAL and TRANSPORT mux category SDP attributes are cases where IDENTICAL and TRANSPORT mux category SDP attributes are
only included in the "m=" sections associated with the BUNDLE-tag. only included in the "m=" sections represented by the BUNDLE-tag.
That means that media-specific IDENTICAL and TRANSPORT mux category That means that media-specific IDENTICAL and TRANSPORT mux category
attributes can be included in an "m=" section associated with another attributes can be included in an "m=" section associated with another
type of media. type of media.
8.2. Generating the Initial SDP Offer 8.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, in order to create a When an offerer generates an initial offer, in order to negotiate a
BUNDLE group, it MUST: BUNDLE group, it MUST:
o Assign a unique address to each "m=" section within the offer, o Assign a unique address to each "m=" section within the offer,
following the procedures in [RFC3264], unless the media line is a following the procedures in [RFC3264], excluding any bundle-only
'bundle-only' "m=" section (see below); and "m=" sections (see below); and
o Include an SDP 'group:BUNDLE' attribute in the offer; and o Include an SDP 'group:BUNDLE' attribute in the offer; and
o Place the identification-tag of each bundled "m=" section in the o Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list; and SDP '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.1]. BUNDLE address [Section 8.2.1].
If the offerer wants to request that the answerer accepts a given If the offerer wants to request that the answerer accepts a given
bundled "m=" section only if the answerer keeps the "m=" section bundled "m=" section only if the answerer keeps the "m=" section
within the BUNDLE group, the offerer MUST: within the BUNDLE group, the offerer MUST:
o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m=" o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m="
secction; and secction; and
o Assign a zero port value to the "m=" section. o Assign a zero port value to the "m=" section.
NOTE: If the offerer assigns a zero port value to an "m=" section, NOTE: If the offerer assigns a zero port value to an "m=" section,
but does not also include an SDP 'bundle-only' attribute in the "m=" but does not include an SDP 'bundle-only' attribute in the "m="
section, it is an indication that the offerer wants to disable the section, it is an indication that the offerer wants to disable the
"m=" section [Section 8.5.4]. "m=" section [Section 8.5.4].
[Section 18.1] shows an example of an initial offer. [Section 18.1] shows an example of an initial offer.
8.2.1. Suggesting the offerer BUNDLE address 8.2.1. Suggesting the offerer BUNDLE address
In the offer, the address:port combination assigned to the "m=" In the offer, the address:port combination assigned to the "m="
section associated with the offerer BUNDLE-tag indicates the section represented by the offerer BUNDLE-tag indicates offerer
address:port combination that the offerer suggests as the offerer BUNDLE address, i.e., the address:port combination that the offerer
BUNDLE address. suggests for sending and receiving bundled media.
The offerer MUST NOT assign a zero port value, or an SDP 'bundle- The offerer BUNDLE-tag MUST NOT represent a bundle-only "m=" section.
only' attribute, to the "m=" section associated with the offerer Hence, the offer MUST contain at least one bundle "m=" section with a
BUNDLE-tag. unique address (and a non-zero port value).
8.2.2. Example: Initial SDP Offer 8.2.2. Example: Initial SDP Offer
The example shows an initial SDP offer. The offer includes two "m=" The example shows an initial SDP offer. The offer includes two "m="
section in the SDP, and suggests that both are included in a BUNDLE section in the SDP, and suggests that both are included in a BUNDLE
group. The audio "m=" section is associated with the offerer BUNDLE- group. The audio "m=" section is associated with the offerer BUNDLE-
tag (placed first in the SDP group:BUNDLE attribute identification-id tag (placed first in the SDP group:BUNDLE attribute identification-id
list). list).
SDP Offer SDP Offer
skipping to change at page 12, line 43 skipping to change at page 12, line 43
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
8.3. Generating the SDP Answer 8.3. Generating the SDP Answer
When an answerer generates an answer that contains a BUNDLE group, When an answerer generates an answer that contains a BUNDLE group,
the following general SDP grouping framework restrictions, defined in the following general SDP grouping framework restrictions, defined in
[RFC5888], also apply to the BUNDLE group: [RFC5888], also apply to the BUNDLE group:
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 negotiated in the
corresponding offer; and corresponding offer; and
o The answerer MUST NOT include an "m=" section within a BUNDLE o The answerer MUST NOT include an "m=" section within a BUNDLE
group, unless the offerer requested the "m=" section to be within group, unless the offerer requested the "m=" section to be within
that BUNDLE group in the corresponding offer. that BUNDLE group in the corresponding offer.
o If the answer contains multiple BUNDLE groups, the answerer MUST o If the answer contains multiple BUNDLE groups, the answerer MUST
NOT move an "m=" section from one BUNDLE group to another. NOT move an "m=" section from one BUNDLE group to another.
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.1]; and o Select an offerer BUNDLE Address [Section 8.3.1]; and
o Select an Answerer BUNDLE Address [Section 8.3.2]; o Select an answerer BUNDLE Address [Section 8.3.2];
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=" section within a BUNDLE If the answerer does not want to keep an "m=" section within a BUNDLE
group, it MUST: group, it MUST:
o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or
o Reject the "m=" section [Section 8.3.4]; o Reject the "m=" section [Section 8.3.4];
If the answerer keeps a bundle-only "m=" section within the BUNDLE When the answerer creates the answer, it selects the offerer BUNDLE
group, it follows the procedures (assigns the answerer BUNDLE address address [Section 8.3.1] and the answerer BUNDLE address
to the "m=" section etc) for any other "m=" section kept within the [Section 8.3.2]. The answerer then assigns the answerer BUNDLE
BUNDLE group. address to the bundled "m=" section represented by the answerer
BUNDLE-tag. In every other bundled "m=" section the answerer
includes an SDP 'bundle-only' attribute and assigns a zero port value
to the "m=" section.
If the answerer does not want to keep a bundle-only "m=" section If the answerer does not want to keep a bundle-only "m=" section
within the BUNDLE group, it MUST reject the "m=" section within the BUNDLE group, it MUST reject the "m=" section
[Section 8.3.4]. [Section 8.3.4].
The answerer MUST NOT include an SDP 'bundle-only' attribute in any
"m=" section in an answer.
NOTE: If a bundled "m=" section in an offer contains a zero port NOTE: If a bundled "m=" section in an offer contains a zero port
value, but the "m=" section does not contain an SDP 'bundle-only' value, but the "m=" section does not contain an SDP 'bundle-only'
attribute, it is an indication that the offerer wants to disable the attribute, it is an indication that the offerer wants to disable the
"m=" section [Section 8.5.4]. "m=" section [Section 8.5.4].
8.3.1. Answerer Selection of Offerer Bundle Address 8.3.1. Answerer Selection of Offerer Bundle Address
In an offer, the address (unique or shared) assigned to the bundled In an offer, the bundled "m=" section represented by the offerer
"m=" section associated with the offerer BUNDLE-tag indicates the BUNDLE-tag contains the suggested offerer BUNDLE address, i.e, the
address that the offerer suggests as the offerer BUNDLE address address:port combination that the offerer wants to use for sending
[Section 8.2.1]. The answerer MUST check whether that "m=" section and receiving bundled media [Section 8.2.1]. The answerer MUST check
fulfils the following criteria: whether that "m=" section fulfils the following criteria:
o The answerer will not move the "m=" section out of the BUNDLE o The answerer will not move the "m=" section out of the BUNDLE
group [Section 8.3.3]; and group [Section 8.3.3]; and
o The answerer will not reject the "m=" section [Section 8.3.4]; and o The answerer will not reject the "m=" section [Section 8.3.4]; and
o The "m=" section does not contain a zero port value. o The "m=" section does not contain a zero port value.
If all of the criteria above are fulfilled, the answerer MUST select If all of the criteria above are fulfilled, the answerer MUST select
the address assigned to the "m=" section as the offerer BUNDLE the suggested offerer BUNDLE address as the offerer BUNDLE address.
address. In the answer, the answerer BUNDLE-tag represents the "m=" In the answer, the answerer BUNDLE-tag represents the "m=" section.
section, and the address assigned to the "m=" section in the offer
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=" section associated and perform the same criteria check for the "m=" section associated
with that identification-tag. If there are no more identification- with that identification-tag. If there are no more identification-
tags in the identification-tag list, the answerer MUST NOT create the tags in the identification-tag list, the answerer MUST NOT create the
BUNDLE group. In addition, unless the answerer rejects the whole BUNDLE group. In addition, unless the answerer rejects the whole
offer, the answerer MUST apply the answerer procedures for moving an offer, the answerer MUST apply the answerer procedures for moving an
"m=" section out of a BUNDLE group [Section 8.3.3] to each bundled "m=" section out of a BUNDLE group [Section 8.3.3] to each bundled
"m=" section in the offer when creating the answer. "m=" section in the offer when creating the answer.
[Section 18.1] shows an example of an offerer BUNDLE address [Section 18.1] shows an example of an offerer BUNDLE address
selection. selection.
8.3.2. Answerer Selection of Answerer BUNDLE Address 8.3.2. 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 (answerer
the answerer BUNDLE address, it MUST assign that address to each BUNDLE address), the answerer MUST assign the answerer BUNDLE address
bundled "m=" section within the created BUNDLE group in the answer. to the "m=" section represented by the answerer BUNDLE-tag (i.e., the
"m=" section in the corresponding offer that contains the selected
offerer BUNDLE address). To every other bundled "m=" section the
answerer MUST assign a zero port value and include an SDP 'bundle-
only' attribute.
The answerer MUST NOT assign the answerer BUNDLE address to an "m=" The answerer MUST NOT assign an answerer BUNDLE address to an "m="
section that is not within the BUNDLE group, or to an "m=" section section that is not within the BUNDLE group, or to an "m=" section
that is within another BUNDLE group. that is within another BUNDLE group.
[Section 18.1] shows an example of an answerer BUNDLE address [Section 18.1] shows an example of an answerer BUNDLE address
selection. selection.
8.3.3. Moving A Media Description Out Of A BUNDLE Group 8.3.3. Moving A Media Description Out Of A BUNDLE Group
When an answerer wants to move an "m=" section out of a BUNDLE group, When an answerer wants to move a bundled "m=" section out of a BUNDLE
it MUST first check the following criteria: group in an answer, it MUST first check the following criteria:
o In the corresponding offer, a shared address (e.g. a previously o In the corresponding offer, an offerer BUNDLE address (previously
selected offerer BUNDLE address) has been assigned to the "m=" selected [Section 8.3.1] or new suggested [Section 8.5.1]) has
section; or been assigned to the "m=" section by the offerer; or
o In the corresponding offer, the "m=" section contains an SDP o In the corresponding offer, the "m=" section contains an SDP
'bundle-only' attribute, and the "m=" section contains a zero port 'bundle-only' attribute and a zero port value.
value.
If either criteria above is fulfilled, the answerer can not not move
the "m=" section out of the BUNDLE group in the answer. The answerer
can either reject the whole offer, or keep the "m=" section within
the BUNDLE group in the answer and later create an offer where the
"m=" section is moved out of the BUNDLE group [Section 8.5.3]
When the answerer generates an answer, in which it removes a bundled
"m=" section out of a BUNDLE group, the answerer:
o MUST assign a unique address to the "m=" section; and
o MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and
o MUST NOT assign an SDP 'bundle-only' attribute to the "m="
section.
An answerer MUST NOT move an "m=" section from one BUNDLE group to An answerer MUST NOT move an "m=" section from one BUNDLE group to
another within an answer. If the answerer wants to move an "m=" another within an answer. If the answerer wants to move an "m="
section from one BUNDLE group to another it MUST first move the section from one BUNDLE group to another it MUST first move the
BUNDLE group out of the current BUNDLE group, and then generate an BUNDLE group out of the current BUNDLE group, and then generate an
offer where the "m=" section is added to another BUNDLE group offer where the "m=" section is added to another BUNDLE group
[Section 8.5.2]. [Section 8.5.2].
If either criteria above is fulfilled, the answerer MUST reject the 8.3.4. Rejecting A Media Description In A BUNDLE Group
"m=" section [Section 8.3.4].
Otherwise, if a unique address has been assigned to the "m=" section When an answerer wants to reject a bundled "m=" section in an answer,
in the corresponding offer, the answerer MUST assign a unique address it MUST first check the following criteria:
to the "m=" section in the answer (the answerer does not reject the
"m=" section).
In addition, in either case above, the answerer MUST NOT place the o In the corresponding offer, an offerer BUNDLE address (previously
identification-tag, associated with the moved "m=" section, in the selected [Section 8.3.1] or new suggested [Section 8.5.1]) has
SDP 'group' attribute identification-tag list associated with the been assigned to the "m=" section by the offerer.
BUNDLE group.
8.3.4. Rejecting A Media Description In A BUNDLE Group If either criteria above is fulfilled, the answerer can not not
reject the "m=" section in the answer. The answerer can either
reject the whole offer, or keep the "m=" section within the BUNDLE
group in the answer and later create an offer where the "m=" section
is disabled of the BUNDLE group [Section 8.5.4]
When an answerer rejects an "m=" section, it MUST assign a zero port When an answerer generates an answer, in which it rejects a bundled
value to "m=" section in the answer, according to the procedures in "m=" section, the answerer:
[RFC3264].
In addition, the answerer MUST NOT place the identification-tag o MUST assign a zero port value to the "m=" section, according to
associated with the rejected "m=" section in the SDP 'group' the procedures in [RFC3264]; and
attribute identification-tag list associated with the BUNDLE group.
o MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and
o MUST NOT assign an SDP 'bundle-only' attribute to the "m="
section.
8.3.5. Example: SDP Answer 8.3.5. Example: SDP Answer
The example shows an SDP answer, based on the SDP offer in The example shows an SDP answer, based on the SDP offer in
[Section 8.2.2]. The answers accepts both "m=" sections within the [Section 8.2.2]. The answers accepts both "m=" sections within the
BUNDLE group. BUNDLE group. The answerer assigns the answerer BUNDLE address to
the "m=" section represented by the answerer BUNDLE-tag. The
answerer assigns a zero port value and an SDP 'bundle-only' attribute
to the other bundled "m=" section.
SDP Answer SDP Answer
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
8.4. Offerer Processing of the SDP Answer 8.4. Offerer Processing of the SDP Answer
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 that any bundled "m=" section in the group, the offerer MUST check that any bundled "m=" section in the
answer was indicated as bundled in the corresponding offer. If there answer was indicated as bundled in the corresponding offer. If there
is no mismatch, the offerer MUST use the offerer BUNDLE address, is no mismatch, the offerer MUST use the offerer BUNDLE address,
selected by the answerer [Section 8.3.1], as the address for each selected by the answerer [Section 8.3.1], as the address for each
skipping to change at page 16, line 44 skipping to change at page 17, line 15
NOTE: As the answerer might reject one or more bundled "m=" sections, NOTE: As the answerer might reject one or more bundled "m=" sections,
or move a bundled "m=" section out of a BUNDLE group, each bundled or move a bundled "m=" section out of a BUNDLE group, each bundled
"m=" section in the offer might not be indicated as bundled in the "m=" section in the offer might not be indicated as bundled in the
answer. answer.
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.5. Modifying the Session 8.5. Modifying the Session
When an offerer generates a subsequent offer, it MUST assign the When an offerer generates a subsequent offer (i.e., a BUNDLE group
previously selected offerer BUNDLE address [Section 8.3.1] to each has previously been negotiated), it MUST assign the previously
bundled "m=" section (including any bundle-only "m=" section), except selected offer BUNDLE address [Section 8.3.1], or a new suggested
if: offerer BUNDLE address [Section 8.5.1], to exactly one "m=" section
within the BUNDLE group.
o The offerer suggests a new offerer BUNDLE address [Section 8.5.1];
or
o The offerer wants to add a bundled "m=" section to the BUNDLE The offerer MUST NOT assign an offerer BUNDLE address (previously
group [Section 8.5.2]; or negotiated or suggested new) to a bundled "m=" section if:
o The offerer wants to move a bundled "m=" section out of the BUNDLE o The offerer wants to move the bundled "m=" section out of the
group [Section 8.5.3]; or BUNDLE group [Section 8.5.3]; or
o The offerer wants to disable the bundled "m=" section o The offerer wants to disable the bundled "m=" section
[Section 8.5.4]. [Section 8.5.4].
In addition, the offerer MUST select an offerer BUNDLE-tag To every other "m=" section within the BUNDLE group, the offerer MUST
[Section 8.2.1] associated with the previously selected offerer assign a zero port value and an SDP 'bundle-only' attribute.
BUNDLE address, unless the offerer suggests a new offerer BUNDLE
address. When the offerer generates a subsequent offer, the offerer BUNDLE-tag
MUST represent the bundled "m=" section to which the offerer BUNDLE
address (previously negotiated or new suggested) has been assigned.
8.5.1. Suggesting a new offerer BUNDLE address 8.5.1. Suggesting 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.1], the offerer MUST: offerer BUNDLE address [Section 8.2.1], the offerer MUST:
o Assign the address (shared address) to each "m=" section within o Assign the new suggested offerer BUNDLE address to exactly one
the BUNDLE group; or "m=" section within the BUNDLE group; and
o Assign the address (unique address) to one bundled "m=" section.
In addition, the offerer MUST indicate that the address is the new
suggested offerer BUNDLE address [Section 8.2.1].
NOTE: Unless the offerer assigns the new suggested offerer BUNDLE o Assign a zero port value and an SDP 'bundle-only' attribute to
address to each bundled "m=" section, it can assign unique addresses every other "m=" section within the BUNDLE group.
to any number of bundled "m=" sections (and the previously selected
offerer BUNDLE address to any remaining bundled "m=" section) if it
wants to suggest multiple alternatives for the new offerer BUNDLE
address.
8.5.2. Adding a media description to a BUNDLE group 8.5.2. 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=" section to a BUNDLE group, the offerer MUST: bundled "m=" section, the offerer MUST:
o Assign a unique address to the added "m=" section; or
o Assign the previously selected offerer BUNDLE address to the added o Assign the offerer BUNDLE address (previously selected
[Section 8.3.1] or new suggested [Section 8.5.1]) to the added
"m=" section; or "m=" section; or
o If the offerer assigns a new (shared address) suggested offerer o Assign a zero port value and an SDP 'bundle-only' attribute to the
BUNDLE address to each bundled "m=" section [Section 8.5.1], also added "m=" section (in this case the offerer BUNDLE address is
assigns that address to the added "m=" section. assigned to another "m=" section within the BUNDLE group).
In addition, the offerer MUST place the identification-tag associated In addition, the offerer MUST place the identification-tag associated
with the added "m=" section in the SDP 'group:BUNDLE' attribute with the added "m=" section in the SDP 'group:BUNDLE' attribute
identification-tag list associated with the BUNDLE group identification-tag list associated with the BUNDLE group
[Section 8.2.1]. [Section 8.2.1].
NOTE: Assigning a unique address to the "m=" section allows the NOTE: If the offerer also wants to suggest a new offerer BUNDLE
answerer to move the "m=" section out of the BUNDLE group address to the BUNDLE group, the offerer can assign the new suggested
[Section 8.3.3], without having to reject the "m=" section. offerer BUNDLE address either to the added "m=" section, or to some
other "m=" section within the BUNDLE group [Section 8.5.1].
If the offerer assigns a unique address to the added "m=" section,
and if the offerer suggests that address as the new offerer BUNDLE
address [Section 8.5.1], the offerer BUNDLE-tag MUST represent the
added "m=" section [Section 8.2.1].
If the offerer associates a new suggested offerer BUNDLE address with
each bundled "m=" section [Section 8.5.1], including the added "m="
section, the offerer BUNDLE-tag MAY represent the added "m=" section
[Section 8.2.1].
[Section 18.3] shows an example where an offerer sends an offer in [Section 18.3] shows an example where an offerer sends an offer in
order to add a bundled "m=" section to a BUNDLE group. order to add a bundled "m=" section to a BUNDLE group.
8.5.3. Moving A Media Description Out Of A BUNDLE Group 8.5.3. 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=" section out of a BUNDLE group it was added to in a bundled "m=" section out of a BUNDLE group, the offerer:
previous offer/answer transaction, the offerer:
o MUST assign a unique address to the "m=" section; and o MUST assign a unique address to the "m=" section; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group. list associated with the BUNDLE group; and
NOTE: If the removed "m=" section is associated with the previously
selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag
[Section 8.2.1].
NOTE: If an "m=" section, when being moved out of a BUNDLE group, is o MUST NOT assign an SDP 'bundle-only' attribute to the "m="
added to another BUNDLE group, the offerer applies the procedures in section.
[Section 8.5.2] to the "m=" section.
An offerer MUST NOT move an "m=" section from one BUNDLE group to An offerer MUST NOT move an "m=" section from one BUNDLE group to
another within a single offer. If the offerer wants to move an "m=" another within a single offer. If the offerer wants to move an "m="
section from one BUNDLE group to another it MUST first move the section from one BUNDLE group to another it MUST first move the
BUNDLE group out of the current BUNDLE group, and then generate a BUNDLE group out of the current BUNDLE group, and then generate a
second offer where the "m=" section is added to another BUNDLE group second offer where the "m=" section is added to another BUNDLE group
[Section 8.5.2]. [Section 8.5.2].
[Section 18.4] shows an example of an offer for moving an "m=" [Section 18.4] shows an example of an offer for moving an "m="
section out of a BUNDLE group. section out of a BUNDLE group.
8.5.4. Disabling A Media Description In A BUNDLE Group 8.5.4. 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=" section (added to the BUNDLE group in a previous offer/ bundled "m=" section, the offerer:
answer transaction), the offerer:
o MUST assign an address with a zero port value to the "m=" section, o MUST assign a zero port value to the "m=" section, following the
following the procedures in [RFC4566]; and procedures in [RFC4566]; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group. list associated with the BUNDLE group; and
o MUST NOT assign an SDP 'bundle-only' attribute to the "m="
section.
[Section 18.5] shows an example of an offer for disabling an "m=" [Section 18.5] shows an example of an offer for disabling an "m="
section within a BUNDLE group. section within a BUNDLE group.
9. Protocol Identification 9. Protocol Identification
Each "m=" section within a BUNDLE group MUST use the same transport- Each "m=" section within a BUNDLE group MUST use the same transport-
layer protocol. If bundled "m=" sections use different protocols on layer protocol. If bundled "m=" sections use different protocols on
top of the transport-layer protocol, there MUST exist a publicly top of the transport-layer protocol, there MUST exist a publicly
available specification which describes a mechanism, for this available specification which describes a mechanism, for this
skipping to change at page 29, line 48 skipping to change at page 29, line 48
The generic procedures for negotiating usage of ICE using SDP, The generic procedures for negotiating usage of ICE using SDP,
defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE
with BUNDLE, with the following exceptions: with BUNDLE, with the following exceptions:
o When the BUNDLE transport has been established, ICE connectivity o When the BUNDLE transport has been established, ICE connectivity
checks and keep-alives only need to be performed for the BUNDLE checks and keep-alives only need to be performed for the BUNDLE
transport, instead of per individual "m=" section within the transport, instead of per individual "m=" section within the
BUNDLE group. BUNDLE group.
o Among bundled "m=" sections (including any bundle-only "m=" o In an offer, if the offer assigns a unique address to one or more
section) to which the offerer has assigned a shared address, the bundled "m=" sections (excluding any bundle-only "m=" section),
offerer only includes ICE-related media-level SDP attributes in the offerer MUST include ICE-related media-level attributes in
the "m=" section associated with the offerer BUNDLE-tag, following each of those "m=" sections. If the offerer assigns an offerer
the procedures in Section 8.1. BUNDLE address (previously selected [Section 8.3.1] or new
suggested [Section 8.5.1]) to a bundled "m=" section (the "m="
section represented by the offerer BUNDLE-tag), the offerer only
includes ICE-related media-level SDP attributes in that "m="
section, following the procedures in Section 8.1.
o Among "m=" sections within a BUNDLE group, to which the answerer o In an answer, the answerer only includes ICE-related media-level
has assigned a shared address within, the answerer only includes SDP attributes in the bundled "m=" section to which the answerer
ICE-related media-level SDP attributes in the "m=" section has assigned the answerer BUNDLE address (the "m=" section
associated with the answerer BUNDLE-tag, following the procedures represented by the answerer BUNDLE-tag), following the procedures
in Section 8.1. in Section 8.1.
Initially, before ICE has produced a candidate pair that will be used Initially, before ICE has produced a candidate pair that will be used
for media, there might by multiple transports established (if for media, there might by multiple transports established (if
multiple candidate pairs are tested). Once ICE has produced a multiple candidate pairs are tested). Once ICE has produced a
transport that will be used for media, that becomes the BUNDLE transport that will be used for media, that becomes the BUNDLE
transport. transport.
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.1. SDP Offer/Answer Procedures 11.1. SDP Offer/Answer Procedures
When an offerer assigns a unique address to a bundled "m=" section When an offerer assigns a unique address to one or more bundled "m="
(excluding any bundle-only "m=" section), the offerer MUST include sections (excluding any bundle-only "m=" section), the offerer MUST
SDP 'candidate' attributes (and other applicable ICE-related media- include SDP 'candidate' attributes (and other applicable ICE-related
level SDP attributes), containing unique ICE properties (candidates media-level SDP attributes), containing unique ICE properties
etc), in the "m=" section according to the procedures in (candidates etc), in each of those "m=" sections, follwoing the
[I-D.ietf-mmusic-ice-sip-sdp]. procedures in [I-D.ietf-mmusic-ice-sip-sdp].
When an offerer assigns a shared address to a bundled "m=" section, When an offerer assigns a BUNDLE address (previously selected or new
the offerer MUST include SDP 'candidate' attributes (and other suggested) to a bundled "m=" section, (the "m=" section represented
applicable ICE-related media-level SDP attributes) in the "m=" by the offerer BUNDLE-tag) the offerer MUST only include SDP
section following the procedures in Section 8.1. 'candidate' attributes (and other applicable ICE-related media-level
SDP attributes) in that "m=" section, following the procedures in
Section 8.1.
When an answerer assigns a shared address to an "m=" section within a When an answerer assigns a BUNDLE address to an "m=" section within a
BUNDLE group, the answerer MUST include SDP 'candidate' attributes BUNDLE group (the "m=" section represented by the answerer BUNDLE-
(and other applicable ICE-related media-level SDP attributes) in the tag), the answerer MUST only include SDP 'candidate' attributes (and
"m=" section following the procedures in Section 8.1. other applicable ICE-related media-level SDP attributes) in that "m="
section, following the procedures in Section 8.1.
NOTE: As most ICE-related media-level SDP attributes belong to the NOTE: As most ICE-related media-level SDP attributes belong to the
TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the
offerer and answerer follow the procedures in Section 8.1 when offerer and answerer follow the procedures in Section 8.1 when
deciding whether to include an attribute in a bundled "m=" section. deciding whether to include an attribute in a bundled "m=" section.
However, in the case of ICE-related media-level attributes, the rules However, in the case of ICE-related media-level attributes, the rules
apply to all attributes (see note below), even if they belong to a apply to all attributes (see note below), even if they belong to a
different mux category. different mux category.
NOTE: The following ICE-related media-level SDP attributes are NOTE: The following ICE-related media-level SDP attributes are
defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote-
candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-
pacing'. pacing'.
11.1.1. Generating the Initial SDP Offer
When an offerer generates an initial offer, the offerer MUST include
ICE-related media-level SDP attributes in bundled "m=" sections
following the procedures in [Section 11.1].
11.1.2. Generating the SDP Answer
When an answerer generates an answer that contains a BUNDLE group,
the answer MUST include ICE-related SDP attributes in "m=" sections
within the BUNDLE group according to [Section 11.1].
11.1.3. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer supports and uses
the ICE mechanism and the BUNDLE extension, the offerer MUST apply
the ICE properties associated with the offerer BUNDLE address,
selected by the answerer [Section 8.3.1], to each bundled "m="
section.
11.1.4. Modifying the Session
When an offerer generates a subsequent offer, it MUST include ICE-
related SDP attributes in a bundled "m=" section following the
procedures in [Section 11.1].
12. DTLS Considerations 12. DTLS Considerations
One or more media streams within a BUNDLE group might use the One or more media streams within a BUNDLE group might use the
Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order
to encrypt the data, or to negotiate encryption keys if another to encrypt the data, or to negotiate encryption keys if another
encryption mechanism is used to encrypt media. encryption mechanism is used to encrypt media.
When DTLS is used within a BUNDLE group, the following rules apply: When DTLS is used within a BUNDLE group, the following rules apply:
o There can only be one DTLS association [RFC6347] associated with o There can only be one DTLS association [RFC6347] associated with
skipping to change at page 39, line 39 skipping to change at page 39, line 19
18.1. Example: Bundle Address Selection 18.1. Example: Bundle Address Selection
The example below shows: The example below shows:
o An offer, in which the offerer assigns a unique address to each o An offer, in which the offerer assigns a unique address to each
bundled "m=" section within the BUNDLE group. bundled "m=" section within the BUNDLE group.
o An answer, in which the answerer selects the offerer BUNDLE o An answer, in which the answerer selects the offerer BUNDLE
address, and then selects its own BUNDLE address (the answerer address, and then selects its own BUNDLE address (the answerer
BUNDLE address) and assigns it to each bundled "m=" section within BUNDLE address) and assigns it to the bundled "m=" section
the BUNDLE group. represented by the answerer BUNDLE-tag.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.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 40, line 43 skipping to change at page 40, line 43
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
18.2. Example: BUNDLE Extension Rejected 18.2. Example: BUNDLE Extension Rejected
The example below shows: The example below shows:
o An offer, in which the offerer assigns a unique address to each o An offer, in which the offerer assigns a unique address to each
bundled "m=" section within the BUNDLE group. bundled "m=" section within the BUNDLE group.
skipping to change at page 43, line 8 skipping to change at page 43, line 8
a=rtcp-mux a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
18.3. Example: Offerer Adds A Media Description To A BUNDLE Group 18.3. Example: Offerer Adds A Media Description To A BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer (the BUNDLE group has been created as part of a
previous offer/answer exchange), in which the offerer adds a new previous offer/answer exchange), in which the offerer adds a new
"m=" section, represented by the "zen" identification-tag, to a "m=" section, represented by the "zen" identification-tag, to a
previously negotiated BUNDLE group, associates a unique address previously negotiated BUNDLE group, assigns the previously
with the added "m=" section, and assigns the previously selected selected offerer BUNDLE address to the added "m=" section,
offerer BUNDLE address to each of the other bundled "m=" sections represented by the offerer BUNDLE-tag. To every other bundled
within the BUNDLE group. "m=" section the offerer assigns a zero port value and includes an
SDP 'bundle-only' attribute.
o An answer, in which the answerer assigns the answerer BUNDLE o An answer, in which the answerer assigns the answerer BUNDLE
address to each bundled "m=" section (including the newly added address to the bundled "m=" section represented by the answerer
"m=" section) within the BUNDLE group. BUNDLE-tag. To every other bundled "m=S section the answerer
assigns a zero port value and includes an SDP 'bundle-only'
attribute.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar zen a=group:BUNDLE zen foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 0 RTP/AVP 0 8 97
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=bundle-only
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32 m=video 0 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 10000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=bundle-only
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar zen a=group:BUNDLE zen foo bar
m=audio 20000 RTP/AVP 0 m=audio 0 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=bundle-only
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
18.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 18.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer (the BUNDLE group has been created as part of a
previous offer/answer transaction), in which the offerer moves a previous offer/answer transaction), in which the offerer moves a
bundled "m=" section out of a BUNDLE group, assigns a unique bundled "m=" section, represented by the "zen" identification-tag,
address to the moved "m=" section, and assigns the offerer BUNDLE out of a BUNDLE group, assigns a unique address to the moved "m="
address to each other bundled "m=" section within the BUNDLE section, and assigns the previously selected offerer BUNDLE
group. address to another bundled "m=" section, represented by the
offerer BUNDLE-tag. To every other bundled "m=" section the
offerer assigns a zero port value and includes an SDP 'bundle-
only' attribute.
o An answer, in which the answerer moves the "m=" section out of the o An answer, in which the answerer moves the "m=" section out of the
BUNDLE group, assigns a unique address to the moved "m=" section, BUNDLE group, assigns a unique address to the moved "m=" section,
and assigns the answerer BUNDLE address to each of the remaining and assigns the answerer BUNDLE address to the bundled "m="
bundled "m=" sections within the BUNDLE group. section represented by the answerer BUNDLE-tag. To every other
bundled "m=" section the answerer assigns a zero port value and
includes an SDP 'bundle-only' attribute.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.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
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32 m=video 0 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 50000 RTP/AVP 66 m=video 50000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
SDP Answer (2) SDP Answer (2)
skipping to change at page 45, line 37 skipping to change at page 46, line 4
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 60000 RTP/AVP 66 m=video 60000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
18.5. Example: Offerer Disables A Media Description Within A BUNDLE 18.5. Example: Offerer Disables A Media Description Within A BUNDLE
Group Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer (the BUNDLE group has been created as part of a
previous offer/answer transaction), in which the offerer disables previous offer/answer transaction), in which the offerer disables
a bundled "m=" section within a BUNDLE group, assigns a zero port a bundled "m=" section represented by the "zen" identification-
number to the disabled "m=" section, and assigns the offerer tag, within a BUNDLE group, assigns a zero port number to the
BUNDLE address to each of the other bundled "m=" sections within disabled "m=" section, and assigns the offerer BUNDLE address to
the BUNDLE group. another bundled "m=" section, represented by the offerer BUNDLE-
tag. To every other bundled "m=" section the offerer assigns a
zero port value and includes an SDP 'bundle-only' attribute.
o An answer, in which the answerer moves the disabled "m=" sections o An answer, in which the answerer moves the disabled "m=" sections
out of the BUNDLE group, assigns a zero port value to the disabled out of the BUNDLE group, assigns a zero port value to the disabled
"m=" section, and assigns the answerer BUNDLE address to each of "m=" section, and assigns the answerer BUNDLE address to the
the remaining bundled "m=" sections within the BUNDLE group. bundled "m=" section represented by the answerer BUNDLE-tag. To
every other bundled "m=" section the answerer assigns a zero port
value and includes an SDP 'bundle-only' attribute.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.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
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 31 32 m=video 0 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
SDP Answer (2) SDP Answer (2)
v=0 v=0
skipping to change at page 47, line 15 skipping to change at page 47, line 33
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
19. Acknowledgements 19. Acknowledgements
The usage of the SDP grouping extension for negotiating bundled media The usage of the SDP grouping extension for negotiating bundled media
is based on a similar alternatives proposed by Harald Alvestrand and is based on a similar alternatives proposed by Harald Alvestrand and
skipping to change at page 48, line 12 skipping to change at page 48, line 30
Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for
providing help and text on the RTP/RTCP procedures. providing help and text on the RTP/RTCP procedures.
Thanks to Spotify for providing music for the countless hours of Thanks to Spotify for providing music for the countless hours of
document editing. document editing.
20. Change Log 20. 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-40
o Editorial changes and technical restrictions in order to make the
specification more understandable:
o https://github.com/cdh4u/draft-sdp-bundle/pull/45
o - BUNDLE address is only assigned to m- section represented by
BUNDLE-tag.
o - bundle-only attribute also used in answers and subsequent
offers.
o - Answerer cannot reject, or remove, the bundled m- section that
contains the BUNDLE address.
o - ICE Offer/Answer sections removed, due to duplicated
information.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39
o Editorial terminology changes. o Editorial terminology changes.
o RFC 5285 reference replaced by reference to RFC 8285. o RFC 5285 reference replaced by reference to RFC 8285.
o https://github.com/cdh4u/draft-sdp-bundle/pull/44 o https://github.com/cdh4u/draft-sdp-bundle/pull/44
o - Clarify that an m- section can not be moved between BUNDLE o - Clarify that an m- section can not be moved between BUNDLE
groups without first moving the m- section out of a BUNDLE group. groups without first moving the m- section out of a BUNDLE group.
skipping to change at page 59, line 14 skipping to change at page 59, line 50
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-12 (work in progress), May 2017. exclusive-12 (work in progress), May 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, Petit-Huguenin, M., Keranen, A., and S. Nandakumar,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-14 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in
progress), October 2017. progress), November 2017.
21.2. Informative References 21.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
 End of changes. 102 change blocks. 
267 lines changed or deleted 287 lines changed or added

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