draft-ietf-mmusic-sdp-bundle-negotiation-51.txt   draft-ietf-mmusic-sdp-bundle-negotiation-52.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264,7941 (if approved) H. Alvestrand Updates: 3264,7941 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: November 3, 2018 C. Jennings Expires: November 25, 2018 C. Jennings
Cisco Cisco
May 2, 2018 May 24, 2018
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-51.txt draft-ietf-mmusic-sdp-bundle-negotiation-52.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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 November 3, 2018. This Internet-Draft will expire on November 25, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9
7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10
7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 10 7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 10
7.1.1. Connection Data (c=) . . . . . . . . . . . . . . . . 10 7.1.1. Connection Data (c=) . . . . . . . . . . . . . . . . 10
7.1.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 11 7.1.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 11
7.1.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . 11 7.1.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . 11
7.2. Generating the Initial SDP Offer . . . . . . . . . . . . 12 7.2. Generating the Initial SDP Offer . . . . . . . . . . . . 12
7.2.1. Suggesting the Offerer tagged 'm=' section . . . . . 13 7.2.1. Suggesting the Offerer tagged 'm=' section . . . . . 13
7.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 13 7.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 13
7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 14 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 14
7.3.1. Answerer Selection of Offerer tagged 'm=' section . . 16 7.3.1. Answerer Selection of tagged 'm=' sections . . . . . 16
7.3.2. Answerer Selection of Answerer tagged 'm=' section . 16 7.3.2. Moving A Media Description Out Of A BUNDLE Group . . 16
7.3.3. Moving A Media Description Out Of A BUNDLE Group . . 16 7.3.3. Rejecting a Media Description in a BUNDLE Group . . . 17
7.3.4. Rejecting a Media Description in a BUNDLE Group . . . 17 7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 18
7.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 18
7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 19 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 19
7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 19 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 19
7.5.1. Adding a Media Description to a BUNDLE group . . . . 20 7.5.1. Adding a Media Description to a BUNDLE group . . . . 20
7.5.2. Moving a Media Description Out of a BUNDLE Group . . 21 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 21
7.5.3. Disabling a Media Description in a BUNDLE Group . . . 21 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 21
8. Protocol Identification . . . . . . . . . . . . . . . . . . . 22 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 22
8.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 22 8.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 22
9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 23 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 23
9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 24 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 24
skipping to change at page 3, line 47 skipping to change at page 3, line 46
13.4. New text replacing section 8.4 (6th paragraph) of RFC 13.4. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14. RTP/RTCP extensions for identification-tag transport . . . . 36 14. RTP/RTCP extensions for identification-tag transport . . . . 36
14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 37 14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 37
14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 37 14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 37
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 38 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 38
15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 38 15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 38
15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 39 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 39
15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 39 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 39
16. Security Considerations . . . . . . . . . . . . . . . . . . . 39 16. Security Considerations . . . . . . . . . . . . . . . . . . . 40
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41
17.1. Example: Tagged m= Section Selections . . . . . . . . . 41 17.1. Example: Tagged m= Section Selections . . . . . . . . . 41
17.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 42 17.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 42
17.3. Example: Offerer Adds a Media Description to a BUNDLE 17.3. Example: Offerer Adds a Media Description to a BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 44 Group . . . . . . . . . . . . . . . . . . . . . . . . . 45
17.4. Example: Offerer Moves a Media Description Out of a 17.4. Example: Offerer Moves a Media Description Out of a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46
17.5. Example: Offerer Disables a Media Description Within a 17.5. Example: Offerer Disables a Media Description Within a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 47 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 48
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 49 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 61
20.1. Normative References . . . . . . . . . . . . . . . . . . 60 20.1. Normative References . . . . . . . . . . . . . . . . . . 61
20.2. Informative References . . . . . . . . . . . . . . . . . 62 20.2. Informative References . . . . . . . . . . . . . . . . . 64
Appendix A. Design Considerations . . . . . . . . . . . . . . . 64 Appendix A. Design Considerations . . . . . . . . . . . . . . . 65
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 64 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 65
A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 66 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 67
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 66 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 67
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 67 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 68
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 67 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 68
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 67 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
1. Introduction 1. Introduction
1.1. Background 1.1. Background
When the SDP offer/answer mechanism [RFC3264] is used to negotiate When the SDP offer/answer mechanism [RFC3264] is used to negotiate
the establishment of multimedia communication sessions, if separate the establishment of multimedia communication sessions, if separate
transports (5-tuples) are negotiated for each individual media transports (5-tuples) are negotiated for each individual media
stream, each transport consumes additional resources (especially when stream, each transport consumes additional resources (especially when
Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE)
skipping to change at page 6, line 27 skipping to change at page 6, line 27
o Unique address:port: An address:port combination that is assigned o Unique address:port: An address:port combination that is assigned
to only one "m=" section in an offer or answer. to only one "m=" section in an offer or answer.
o Offerer BUNDLE-tag: The first identification-tag in a given SDP o 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.
o Answerer BUNDLE-tag: The first identification-tag in a given SDP o 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.
o Suggested offerer tagged "m=" section: The bundled "m=" section o Suggested offerer tagged "m=" section: The bundled "m=" section
identified by the offerer BUNDLE-tag in an initial offer, before a identified by the offerer BUNDLE-tag in an initial BUNDLE offer,
BUNDLE group has been negotiated. before a BUNDLE group has been negotiated.
o Offerer tagged "m=" section: The bundled "m=" section identified o Offerer tagged "m=" section: The bundled "m=" section identified
by the offerer BUNDLE-tag in a subsequent offer. The "m=" section by the offerer BUNDLE-tag in a subsequent offer. The "m=" section
contains characteristics (offerer BUNDLE address:port and offerer contains characteristics (offerer BUNDLE address:port and offerer
BUNDLE attributes) applied to each "m=" section within the BUNDLE BUNDLE attributes) applied to each "m=" section within the BUNDLE
group. group.
o Answerer tagged "m=" section: The bundled "m=" section identified o Answerer tagged "m=" section: The bundled "m=" section identified
by the answerer BUNDLE-tag in an answer (initial or subsequent). by the answerer BUNDLE-tag in an answer (initial BUNDLE answer or
The "m=" section contains characteristics (answerer BUNDLE subsequent). The "m=" section contains characteristics (answerer
address:port and answerer BUNDLE attributes) applied to each "m=" BUNDLE address:port and answerer BUNDLE attributes) applied to
section within the BUNDLE group. each "m=" section within the BUNDLE group.
o BUNDLE address:port: An address:port combination that an endpoint o BUNDLE address:port: An address:port combination that an endpoint
uses for sending and receiving bundled media. uses for sending and receiving bundled media.
o Offerer BUNDLE address:port: the address:port combination used by o Offerer BUNDLE address:port: the address:port combination used by
the offerer for sending and receiving media. the offerer for sending and receiving media.
o Answerer BUNDLE address:port: the address:port combination used by o Answerer BUNDLE address:port: the address:port combination used by
the answerer for sending and receiving media. the answerer for sending and receiving media.
skipping to change at page 7, line 34 skipping to change at page 7, line 34
o Bundled "m=" section: An "m=" section, whose identification-tag is o Bundled "m=" section: An "m=" section, whose identification-tag is
placed in an SDP 'group:BUNDLE' attribute identification-tag list placed in an SDP 'group:BUNDLE' attribute identification-tag list
in an offer or answer. in an offer or answer.
o Bundle-only "m=" section: A bundled "m=" section that contains an o Bundle-only "m=" section: A bundled "m=" section that contains an
SDP 'bundle-only' attribute. SDP 'bundle-only' attribute.
o Bundled media: All media associated with a given BUNDLE group. o Bundled media: All media associated with a given BUNDLE group.
o Initial offer: The first offer, within an SDP session (e.g. a SIP o Initial BUNDLE offer: The first offer, within an SDP session (e.g.
dialog when the Session Initiation Protocol (SIP) [RFC3261] is a SIP dialog when the Session Initiation Protocol (SIP) [RFC3261]
used to carry SDP), in which the offerer indicates that it wants is used to carry SDP), in which the offerer indicates that it
to negotiate a given BUNDLE group. wants to negotiate a given BUNDLE group.
o Initial answer: The answer to an initial offer in which the o Initial BUNDLE answer: The answer to an initial BUNDLE offer in
offerer indicates that it wants to negotiate a BUNDLE group, and which the offerer indicates that it wants to negotiate a BUNDLE
where the answerer accepts the creation of the BUNDLE group. The group, and where the answerer accepts the creation of the BUNDLE
BUNDLE group is created once the answerer sends the initial group. The BUNDLE group is created once the answerer sends the
answer. initial BUNDLE answer.
o Subsequent offer: An offer which contains a BUNDLE group that has o 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.
o Subsequent answer: An answer to a subsequent offer. o Subsequent answer: An answer to a subsequent offer.
o Identification-tag: A unique token value that is used to identify o Identification-tag: A unique token value that is used to identify
an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m="
section carries the unique identification-tag assigned to that section carries the unique identification-tag assigned to that
"m=" section. The session-level SDP 'group' attribute [RFC5888] "m=" section. The session-level SDP 'group' attribute [RFC5888]
skipping to change at page 11, line 25 skipping to change at page 11, line 25
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=" sections. bandwidth (b=) line with bundled "m=" sections.
7.1.3. Attributes (a=) 7.1.3. Attributes (a=)
An offerer and answerer MUST include SDP attributes in every bundled An offerer and answerer MUST include SDP attributes in every bundled
"m=" section where applicable, following the normal offer/answer "m=" section where applicable, following the normal offer/answer
procedures for each attribute, with the following exceptions: procedures for each attribute, with the following exceptions:
o In the initial offerer, the offerer MUST NOT include IDENTICAL and o In the initial BUNDLE offer, the offerer MUST NOT include
TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) IDENTICAL and TRANSPORT multiplexing category SDP attributes
in bundle-only "m=" sections. The offerer MUST included such (BUNDLE attributes) in bundle-only "m=" sections. The offerer
attributes in all other bundled "m=" sections. In the initial MUST include such attributes in all other bundled "m=" sections.
offer each bundled "m=" line can contain a different set of BUNDLE In the initial BUNDLE offer each bundled "m=" line can contain a
attributes, and attribute values. Once the offerer tagged "m=" different set of BUNDLE attributes, and attribute values. Once
section has been selected, the BUNDLE attributes contained in the the offerer tagged "m=" section has been selected, the BUNDLE
offerer tagged "m=" section will apply to each bundled "m=" attributes contained in the offerer tagged "m=" section will apply
section within the BUNDLE group. to each bundled "m=" section within the BUNDLE group.
o In a subsequent offer, or in an answer (initial of subsequent), o In a subsequent offer, or in an answer (initial of subsequent),
the offerer and answerer MUST include IDENTICAL and TRANSPORT the offerer and answerer MUST include IDENTICAL and TRANSPORT
multiplexing category SDP attributes (BUNDLE attributes) only in multiplexing category SDP attributes (BUNDLE attributes) only in
the tagged "m=" section (offerer tagged "m=" section or answerer the tagged "m=" section (offerer tagged "m=" section or answerer
tagged "m=" section). The offerer and answerer MUST NOT include tagged "m=" section). The offerer and answerer MUST NOT include
such attributes in any other bundled "m=" section. The BUNDLE such attributes in any other bundled "m=" section. The BUNDLE
attributes contained in the tagged "m=" section will apply to each attributes contained in the tagged "m=" section will apply to each
bundled "m=" section within the BUNDLE group. bundled "m=" section within the BUNDLE group.
o In an offer (initial or subsequent), or in an answer (initial or o In an offer (initial BUNDLE offer or subsequent), or in an answer
subsequent), the offerer and answerer MUST include SDP attributes (initial BUNDLE answer or subsequent), the offerer and answerer
of other categories than IDENTICAL and TRANSPORT in each bundled MUST include SDP attributes of other categories than IDENTICAL and
"m=" section that a given attribute applies to. Each bundled "m=" TRANSPORT in each bundled "m=" section that a given attribute
line can contain a different set of such attributes, and attribute applies to. Each bundled "m=" line can contain a different set of
values, as such attributes only apply to the given bundled "m=" such attributes, and attribute values, as such attributes only
section in which they are included. apply to the given bundled "m=" section in which they are
included.
NOTE: A consequence of the rules above is that media-specific NOTE: A consequence of the rules above is that media-specific
IDENTICAL and TRANSPORT multiplexing category SDP attributes which IDENTICAL and TRANSPORT multiplexing category SDP attributes which
are applicable only to some of the bundled "m=" sections within the are applicable only to some of the bundled "m=" sections within the
BUNDLE group might appear in the tagged "m=" section for which they BUNDLE group might appear in the tagged "m=" section for which they
are not applicable. For instance, the tagged "m=" section might are not applicable. For instance, the tagged "m=" section might
contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section
does not describe RTP-based media (but another bundled "m=" section does not describe RTP-based media (but another bundled "m=" section
within the BUNDLE group does describe RTP-based media). within the BUNDLE group does describe RTP-based media).
7.2. Generating the Initial SDP Offer 7.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, in order to negotiate a The procedures in this section apply to the first offer, within an
BUNDLE group, it MUST: SDP session (e.g. a SIP dialog when the Session Initiation Protocol
(SIP) [RFC3261] is used to carry SDP), in which the offerer indicates
that it wants to negotiate a given BUNDLE group. This could occur in
the initial offer, or in a subsequent offer, of the SDP session.
When an offerer generates an initial BUNDLE offer, in order to
negotiate a BUNDLE group, it MUST:
o Assign a unique address:port to each bundled "m=" section, o Assign a unique address:port to each bundled "m=" section,
following the procedures in [RFC3264], excluding any bundle-only following the procedures in [RFC3264], excluding any bundle-only
"m=" sections (see below); and "m=" sections (see below); and
o Pick a bundled "m=" section as the suggested offerer tagged "m=" o Pick a bundled "m=" section as the suggested offerer tagged "m="
section [Section 7.2.1]; and section [Section 7.2.1]; and
o Include SDP attributes in the bundled "m=" sections following the o Include SDP attributes in the bundled "m=" sections following the
rules in [Section 7.1.3]; and rules in [Section 7.1.3]; and
skipping to change at page 13, line 8 skipping to change at page 13, line 16
section; and section; 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 a bundled "m=" NOTE: If the offerer assigns a zero port value to a bundled "m="
section, but does not include an SDP 'bundle-only' attribute in the section, but does not include an SDP 'bundle-only' attribute in the
"m=" section, it is an indication that the offerer wants to disable "m=" section, it is an indication that the offerer wants to disable
the "m=" section [Section 7.5.3]. the "m=" section [Section 7.5.3].
[Section 7.2.2] and [Section 17.1] show an example of an initial [Section 7.2.2] and [Section 17.1] show an example of an initial
offer. BUNDLE offer.
7.2.1. Suggesting the Offerer tagged 'm=' section 7.2.1. Suggesting the Offerer tagged 'm=' section
In the initial offer, the bundled "m=" section indicated by the In the initial BUNDLE offer, the bundled "m=" section indicated by
offerer BUNDLE-tag is the suggested offerer tagged "m=" section. The the offerer BUNDLE-tag is the suggested offerer tagged "m=" section.
address:port combination associated with the "m=" section will be The address:port combination associated with the "m=" section will be
used by the offerer for sending and receiving bundled media if the used by the offerer for sending and receiving bundled media if the
answerer selects the "m=" section as the offerer tagged "m=" section answerer selects the "m=" section as the offerer tagged "m=" section
[Section 7.3.1]. In addition, if the answerer selects the "m=" [Section 7.3.1]. In addition, if the answerer selects the "m="
section as the offerer tagged "m=" section, the BUNDLE attributes section as the offerer tagged "m=" section, the BUNDLE attributes
included in the "m=" section will be applied to each "m=" section included in the "m=" section will be applied to each "m=" section
within the negotiated BUNDLE group. within the negotiated BUNDLE group.
The offerer MUST NOT suggest a bundle-only "m=" section as the The offerer MUST NOT suggest a bundle-only "m=" section as the
offerer tagged "m=" section. offerer tagged "m=" section.
It is RECOMMENDED that the suggested offerer tagged "m=" section is a It is RECOMMENDED that the suggested offerer tagged "m=" section is a
bundled "m=" section that the offerer believes it is unlikely that bundled "m=" section that the offerer believes it is unlikely that
the answerer will reject, or move out of the BUNDLE group. How such the answerer will reject, or move out of the BUNDLE group. How such
assumption is made is outside the scope of this document. assumption is made is outside the scope of this document.
7.2.2. Example: Initial SDP Offer 7.2.2. Example: Initial SDP Offer
The example shows an initial offer. The offer includes two "m=" The example shows an initial BUNDLE offer. The offer includes two
sections in the offer, and suggests that both "m=" sections are "m=" sections in the offer, and suggests that both "m=" sections are
included in a BUNDLE group. The audio "m=" section is the suggested included in a BUNDLE group. The audio "m=" section is the suggested
offerer tagged "m=" section, indicated by placing the identification- offerer tagged "m=" section, indicated by placing the identification-
tag associated with the "m=" section (offerer BUNDLE-tag) first in tag associated with the "m=" section (offerer BUNDLE-tag) first in
the SDP group:BUNDLE attribute identification-id list. the SDP group:BUNDLE attribute identification-id list.
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
skipping to change at page 14, line 33 skipping to change at page 14, line 33
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux a=rtcp-mux
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
7.3. Generating the SDP Answer 7.3. Generating the SDP Answer
When an answerer generates an answer (initial or subsequent) that When an answerer generates an answer (initial BUNDLE answer or
contains a BUNDLE group the following general SDP grouping framework subsequent) that contains a BUNDLE group the following general SDP
restrictions, defined in [RFC5888], also apply to the BUNDLE group: grouping framework restrictions, defined in [RFC5888], also apply to
the BUNDLE group:
o The answerer is only allowed to include a BUNDLE group in an o The answerer is only allowed to include a BUNDLE group in an
initial answer if the offerer requested the BUNDLE group to be initial BUNDLE answer if the offerer requested the BUNDLE group to
created in the corresponding initial offer; and be created in the corresponding initial BUNDLE offer; and
o The answerer is only allowed to include a BUNDLE group in a o The answerer is only allowed to include a BUNDLE group in a
subsequent answer if the corresponding subsequent offer contains a subsequent answer if the corresponding subsequent offer contains a
previously negotiated BUNDLE group; and previously negotiated BUNDLE group; and
o The answerer is only allowed to include a bundled "m=" section in o The answerer is only allowed to include a bundled "m=" section in
an answer if the "m=" section was indicated as bundled in the an answer if the "m=" section was indicated as bundled in the
corresponding offer; and corresponding offer; and
o The answerer is only allowed to include a bundled "m=" section in o The answerer is only allowed to include a bundled "m=" section in
the same BUNDLE group as the bundled "m=" line in the the same BUNDLE group as the bundled "m=" line in the
corresponding offer. corresponding offer.
In addition, when an answerer generates an answer (initial or In addition, when an answerer generates an answer (initial BUNDLE
subsequent) that contains a BUNDLE group, the answerer MUST: answer or subsequent) that contains a BUNDLE group, the answerer
MUST:
o In case of an initial answer, select the offerer tagged "m=" o In case of an initial BUNDLE answer, select the offerer tagged
section using the procedures in Section 7.3.1. In case of a "m=" section using the procedures in Section 7.3.1. In case of a
subsequent answer, the offerer tagged "m=" section is indicated in subsequent answer, the offerer tagged "m=" section is indicated in
the corresponding subsequent offer, and MUST NOT be changed by the the corresponding subsequent offer, and MUST NOT be changed by the
answerer; and answerer; and
o Select the answerer tagged "m=" section [Section 7.3.2]; and o Select the answerer tagged "m=" section [Section 7.3.1]; and
o Assign the answerer BUNDLE address:port to the answerer tagged o Assign the answerer BUNDLE address:port to the answerer tagged
"m=" section; and "m=" section; and
o Include an SDP 'bundle-only' attribute in, and assign a zero port o Include an SDP 'bundle-only' attribute in, and assign a zero port
value to, every other bundled "m=" section within the BUNDLE value to, every other bundled "m=" section within the BUNDLE
group; and group; and
o Include SDP attributes in the bundled "m=" sections following the o Include SDP attributes in the bundled "m=" sections following the
rules in [Section 7.1.3]; and rules in [Section 7.1.3]; and
o Include an SDP 'group:BUNDLE' attribute in the answer; and o Include an SDP 'group:BUNDLE' attribute in the answer; 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. The SDP 'group:BUNDLE' attribute identification-tag list. The
answerer BUNDLE-tag indicates the answerer tagged "m=" section answerer BUNDLE-tag indicates the answerer tagged "m=" section
[Section 7.3.2]. [Section 7.3.1].
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 7.3.3]; or o Move the "m=" section out of the BUNDLE group [Section 7.3.2]; or
o Reject the "m=" section [Section 7.3.4]. o Reject the "m=" section [Section 7.3.3].
The answerer can modify the answerer BUNDLE address:port, add and The answerer can modify the answerer BUNDLE address:port, add and
remove SDP attributes, or modify SDP attribute values, in a remove SDP attributes, or modify SDP attribute values, in a
subsequent answer. Changes to the answerer BUNDLE address:port and subsequent answer. Changes to the answerer BUNDLE address:port and
the answerer BUNDLE attributes will be applied to each bundled "m=" the answerer BUNDLE attributes will be applied to each bundled "m="
section within the BUNDLE group. section within the BUNDLE group.
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 7.5.3]. "m=" section [Section 7.5.3].
7.3.1. Answerer Selection of Offerer tagged 'm=' section 7.3.1. Answerer Selection of tagged 'm=' sections
When the answerer selects the offerer tagged "m=" section, it first When the answerer selects the offerer tagged "m=" section, it first
checks the suggested offerer tagged "m=" section [Section 7.2.1]. checks the suggested offerer tagged "m=" section [Section 7.2.1].
The answerer MUST check whether the "m=" section fulfils the The answerer MUST check whether the "m=" section fulfils the
following criteria: 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 7.3.3]; and group [Section 7.3.2]; and
o The answerer will not reject the "m=" section [Section 7.3.4]; and o The answerer will not reject the "m=" section [Section 7.3.3]; 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 "m=" section as the offerer tagged "m=" section. the "m=" section as the offerer tagged "m=" section, and MUST also
mark the corresponding "m=" section in the answer as the answerer
tagged "m=" section. In the answer the answerer BUNDLE-tag indicates
the answerer tagged "m=" section.
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
pick the next identification-tag in the identification-tag list in pick the next identification-tag in the identification-tag list in
the offer, and perform the same criteria check for the "m=" section the offer, and perform the same criteria check for the "m=" section
indicated by that identification-tag. If there are no more indicated by that identification-tag. If there are no more
identification-tags in the identification-tag list, the answerer MUST identification-tags in the identification-tag list, the answerer MUST
NOT create the BUNDLE group. Unless the answerer rejects the whole NOT create the BUNDLE group. 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 7.3.3] or rejecting an "m=" section out of a BUNDLE group [Section 7.3.2] or rejecting an
"m=" section within a BUNDLE group [Section 7.3.4] to every bundled "m=" section within a BUNDLE group [Section 7.3.3] to every bundled
"m=" section in the offer when creating the answer. "m=" section in the offer when creating the answer.
[Section 17.1] shows an example of an offerer BUNDLE address:port [Section 17.1] shows an example of an offerer BUNDLE address:port
selection. selection.
7.3.2. Answerer Selection of Answerer tagged 'm=' section [Section 7.3.4] and [Section 17.1] show an example of an answerer
The answerer MUST select the "m=" section in that corresponds to the
selected offerer tagged "m=" section in the corresponding offer
[Section 7.3.1] as the answerer tagged "m=" section. In the answer
the answerer BUNDLE-tag indicates the answerer tagged "m=" section.
[Section 7.3.5] and [Section 17.1] show an example of an answerer
tagged "m=" section selection. tagged "m=" section selection.
7.3.3. Moving A Media Description Out Of A BUNDLE Group 7.3.2. Moving A Media Description Out Of A BUNDLE Group
When an answerer generates the answer, if the answerer wants to move When an answerer generates the answer, if the answerer wants to move
a bundled "m=" section out of the negotiated BUNDLE group, the a bundled "m=" section out of the negotiated BUNDLE group, the
answerer MUST first check the following criteria: answerer MUST first check the following criteria:
o In the corresponding offer, the "m=" section is within a o In the corresponding offer, the "m=" section is within a
previously negotiated BUNDLE group; and previously negotiated BUNDLE group; and
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. 'bundle-only' attribute.
If either criterium above is fulfilled the answerer can not move the If either criterium above is fulfilled the answerer can not move the
"m=" section out of the BUNDLE group in the answer. The answerer can "m=" section out of the BUNDLE group in the answer. The answerer can
either reject the whole offer, reject each bundled "m=" section either reject the whole offer, reject each bundled "m=" section
within the BUNDLE group [Section 7.3.4], or keep the "m=" section within the BUNDLE group [Section 7.3.3], or keep the "m=" section
within the BUNDLE group in the answer and later create an offer where within the BUNDLE group in the answer and later create an offer where
the "m=" section is moved out of the BUNDLE group [Section 7.5.2]. the "m=" section is moved out of the BUNDLE group [Section 7.5.2].
NOTE: One consequence of the rules above is that, once a BUNDLE group NOTE: One consequence of the rules above is that, once a BUNDLE group
has been negotiated, a bundled "m=" section can not be moved out of has been negotiated, a bundled "m=" section can not be moved out of
the BUNDLE group in an answer. Instead an offer is needed. the BUNDLE group in an answer. Instead an offer is needed.
When the answerer generates an answer, in which it moves a bundled When the answerer generates an answer, in which it moves a bundled
"m=" section out of a BUNDLE group, the answerer: "m=" section out of a BUNDLE group, the answerer:
skipping to change at page 17, line 45 skipping to change at page 17, line 42
o MUST NOT include an SDP 'bundle-only' attribute to the "m=" o MUST NOT include an SDP 'bundle-only' attribute to the "m="
section; and section; and
Because an answerer is not allowed to move an "m=" section from one Because an answerer is not allowed to move an "m=" section from one
BUNDLE group to another within an answer [Section 7.3], if the BUNDLE group to another within an answer [Section 7.3], if the
answerer wants to move an "m=" section from one BUNDLE group to answerer wants to move an "m=" section from one BUNDLE group to
another it MUST first move the "m=" section out of the current BUNDLE another it MUST first move the "m=" section out of the current BUNDLE
group, and then generate an offer where the "m=" section is added to group, and then generate an offer where the "m=" section is added to
another BUNDLE group [Section 7.5.1]. another BUNDLE group [Section 7.5.1].
7.3.4. Rejecting a Media Description in a BUNDLE Group 7.3.3. Rejecting a Media Description in a BUNDLE Group
When an answerer wants to reject a bundled "m=" section in an answer, When an answerer wants to reject a bundled "m=" section in an answer,
it MUST first check the following criterium: it MUST first check the following criterion:
o In the corresponding offer, the "m=" section is the offerer tagged o In the corresponding offer, the "m=" section is the offerer tagged
"m=" section. "m=" section.
If the criterium above is fulfilled the answerer can not reject the If the criterium above is fulfilled the answerer can not reject the
"m=" section in the answer. The answerer can either reject the whole "m=" section in the answer. The answerer can either reject the whole
offer, reject each bundled "m=" section within the BUNDLE group, or offer, reject each bundled "m=" section within the BUNDLE group, or
keep the "m=" section within the BUNDLE group in the answer and later keep the "m=" section within the BUNDLE group in the answer and later
create an offer where the "m=" section is disabled within the BUNDLE create an offer where the "m=" section is disabled within the BUNDLE
group [Section 7.5.3]. group [Section 7.5.3].
skipping to change at page 18, line 25 skipping to change at page 18, line 21
o MUST assign a zero port value to the "m=" section, according to o MUST assign a zero port value to the "m=" section, according to
the procedures in [RFC3264]; and the procedures in [RFC3264]; 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; and list associated with the BUNDLE group; and
o MUST NOT include an SDP 'bundle-only' attribute in the "m=" o MUST NOT include an SDP 'bundle-only' attribute in the "m="
section. section.
7.3.5. Example: SDP Answer 7.3.4. Example: SDP Answer
The example below shows an answer, based on the corresponding offer The example below shows an answer, based on the corresponding offer
in [Section 7.2.2]. The answerer accepts both bundled "m=" sections in [Section 7.2.2]. The answerer accepts both bundled "m=" sections
within the created BUNDLE group. The audio "m=" section is the within the created BUNDLE group. The audio "m=" section is the
answerer tagged "m=" section, indicated by placing the answerer tagged "m=" section, indicated by placing the
identification-tag associated with the "m=" section (answerer BUNDLE- identification-tag associated with the "m=" section (answerer BUNDLE-
tag) first in the SDP group;BUNDLE attribute identification-id list. tag) first in the SDP group;BUNDLE attribute identification-id list.
The answerer includes an SDP 'bundle-only' attribute in, and assigns The answerer includes an SDP 'bundle-only' attribute in, and assigns
a zero port value to, the video "m=" section. a zero port value to, the video "m=" section.
skipping to change at page 19, line 39 skipping to change at page 19, line 39
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 apply the properties (BUNDLE is no mismatch, the offerer MUST apply the properties (BUNDLE
address:port, BUNDLE attributes etc) of the offerer tagged "m=" address:port, BUNDLE attributes etc) of the offerer tagged "m="
section (selected by the answerer [Section 7.3.1]) to each bundled section (selected by the answerer [Section 7.3.1]) to each bundled
"m=" section within the BUNDLE group. "m=" section within the BUNDLE group.
NOTE: As the answerer might reject one or more bundled "m=" sections NOTE: As the answerer might reject one or more bundled "m=" sections
in an initial offer, or move a bundled "m=" section out of a BUNDLE in an initial BUNDLE offer, or move a bundled "m=" section out of a
group, a given bundled "m=" section in the offer might not be BUNDLE group, a given bundled "m=" section in the offer might not be
indicated as bundled in the corresponding answer. indicated as bundled in the corresponding 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.
7.5. Modifying the Session 7.5. Modifying the Session
When a BUNDLE group has previously been negotiated, and an offerer When a BUNDLE group has previously been negotiated, and an offerer
generates a subsequent offer, the offerer MUST: generates a subsequent offer, the offerer MUST:
skipping to change at page 20, line 45 skipping to change at page 20, line 45
remove SDP attributes, or modify SDP attribute values, in the remove SDP attributes, or modify SDP attribute values, in the
subsequent offer. Changes to the offerer BUNDLE address:port and the subsequent offer. Changes to the offerer BUNDLE address:port and the
offerer BUNDLE attributes will (if the offer is accepted by the offerer BUNDLE attributes will (if the offer is accepted by the
answerer) be applied to each bundled "m=" section within the BUNDLE answerer) be applied to each bundled "m=" section within the BUNDLE
group. group.
7.5.1. Adding a Media Description to a BUNDLE group 7.5.1. Adding a Media Description to a BUNDLE group
When an offerer generates a subsequent offer, in which it wants to When an offerer generates a subsequent offer, in which it wants to
add a bundled "m=" section to a previously negotiated BUNDLE group, add a bundled "m=" section to a previously negotiated BUNDLE group,
the offerer follows the procedures in [Section 7.5]. The offerer the offerer follows the procedures in Section 7.5. The offerer
either picks the added "m=" section, or an "m=" section previously either picks the added "m=" section, or an "m=" section previously
added to the BUNDLE group, as the offerer tagged "m=" section. added to the BUNDLE group, as the offerer tagged "m=" section.
NOTE: As described in Section 7.3.2, the answerer can not move the
added "m=" section out of the BUNDLE group in its answer. If the
answer wants to move the "m=" section out of the BUNDLE group, it
will have to first accept it into the BUNDLE group in the answer, and
then send a subsequent offer where the "m=" section is moved out of
the BUNDLE group [Section 7.5.2].
7.5.2. Moving a Media Description Out of a BUNDLE Group 7.5.2. Moving a Media Description Out of a BUNDLE Group
When an offerer generates a subsequent offer, in which it want to When an offerer generates a subsequent offer, in which it want to
remove a bundled "m=" section from a BUNDLE group, the offerer: remove a bundled "m=" section from a BUNDLE group, the offerer:
o MUST assign a unique address:port to the "m=" section; and o MUST assign a unique address:port to the "m=" section; and
o MUST include SDP attributes in the "m=" section following the o MUST include SDP attributes in the "m=" section following the
normal offer/answer rules for each attribute; and normal offer/answer rules for each attribute; and
skipping to change at page 30, line 26 skipping to change at page 30, line 30
mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute
[I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP
multiplexing for RTP-based bundled media. multiplexing for RTP-based bundled media.
RTP/RTCP multiplexing only applies to RTP-based media. However, as RTP/RTCP multiplexing only applies to RTP-based media. However, as
described in Section 7.1.3, within an offer or answer the SDP 'rtcp- described in Section 7.1.3, within an offer or answer the SDP 'rtcp-
mux' and SDP 'rtcp-mux-only' attributes might be included in a mux' and SDP 'rtcp-mux-only' attributes might be included in a
bundled "m=" section for non-RTP-based media (if such "m=" section is bundled "m=" section for non-RTP-based media (if such "m=" section is
the offerer tagged "m=" section or answerer tagged "m=" section). the offerer tagged "m=" section or answerer tagged "m=" section).
9.3.1.1. Generating the Initial SDP Offer 9.3.1.1. Generating the Initial SDP BUNDLE Offer
When an offerer generates an initial offer, if the offer contains one When an offerer generates an initial BUNDLE offer, if the offer
or more bundled "m=" sections for RTP-based media (or, if there is a contains one or more bundled "m=" sections for RTP-based media (or,
chance that "m=" sections for RTP-based media will later be added to if there is a chance that "m=" sections for RTP-based media will
the BUNDLE group), the offerer MUST include an SDP 'rtcp-mux' later be added to the BUNDLE group), the offerer MUST include an SDP
attribute [RFC5761] in each bundled "m=" section (excluding any 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section
bundle-only "m=" sections). In addition, the offerer MAY include an (excluding any bundle-only "m=" sections). In addition, the offerer
SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in one MAY include an SDP 'rtcp-mux-only' attribute
or more bundled "m=" sections for RTP-based media. [I-D.ietf-mmusic-mux-exclusive] in one or more bundled "m=" sections
for RTP-based media.
NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute
depends on whether the offerer supports fallback to usage of a depends on whether the offerer supports fallback to usage of a
separate port for RTCP in case the answerer moves one or more "m=" separate port for RTCP in case the answerer moves one or more "m="
sections for RTP-based media out of the BUNDLE group in the answer. sections for RTP-based media out of the BUNDLE group in the answer.
NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the
bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' bundled "m=" sections, but does not include an SDP 'rtcp-mux-only'
attribute, the offerer can also include an SDP 'rtcp' attribute attribute, the offerer can also include an SDP 'rtcp' attribute
[RFC3605] in one or more RTP-based bundled "m=" sections in order to [RFC3605] in one or more RTP-based bundled "m=" sections in order to
provide a fallback port for RTCP, as described in [RFC5761]. provide a fallback port for RTCP, as described in [RFC5761].
However, the fallback port will only be applied to "m=" sections for However, the fallback port will only be applied to "m=" sections for
RTP-based media that are moved out of the BUNDLE group by the RTP-based media that are moved out of the BUNDLE group by the
answerer. answerer.
In the initial offer, the address:port combination for RTCP MUST be In the initial BUNDLE offer, the address:port combination for RTCP
unique in each bundled "m=" section for RTP-based media (excluding a MUST be unique in each bundled "m=" section for RTP-based media
bundle-only "m=" section), similar to RTP. (excluding a bundle-only "m=" section), similar to RTP.
9.3.1.2. Generating the SDP Answer 9.3.1.2. Generating the SDP Answer
When an answerer generates an answer, if the answerer supports RTP- When an answerer generates an answer, if the answerer supports RTP-
based media, and if a bundled "m=" section in the corresponding offer based media, and if a bundled "m=" section in the corresponding offer
contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage
of RTP/RTCP multiplexing, even if there currently are no bundled "m=" of RTP/RTCP multiplexing, even if there currently are no bundled "m="
sections for RTP-based media within the BUNDLE group. The answerer sections for RTP-based media within the BUNDLE group. The answerer
MUST include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" MUST include an SDP 'rtcp-mux' attribute in the answerer tagged "m="
section, following the procedures for BUNDLE attributes section, following the procedures for BUNDLE attributes
[Section 7.1.3]. In addition, if the "m=" section that is selected [Section 7.1.3]. In addition, if the "m=" section that is selected
as the offerer tagged "m=" section contained an SDP "rtcp-mux-only" as the offerer tagged "m=" section contained an SDP "rtcp-mux-only"
attribute, the answerer MUST include an SDP "rtcp-mux-only" attribute attribute, the answerer MUST include an SDP "rtcp-mux-only" attribute
in the answerer tagged "m=" section. in the answerer tagged "m=" section.
In an initial offer, if the suggested offerer tagged "m=" section In an initial BUNDLE offer, if the suggested offerer tagged "m="
contained an SDP 'rtcp-mux-only' attribute, the "m=" section was for section contained an SDP 'rtcp-mux-only' attribute, the "m=" section
RTP-based media, and the answerer does not accept the "m=" section in was for RTP-based media, and the answerer does not accept the "m="
the created BUNDLE group, the answerer MUST either move the "m=" section in the created BUNDLE group, the answerer MUST either move
section out of the BUNDLE group [Section 7.3.3], include the the "m=" section out of the BUNDLE group [Section 7.3.2], include the
attribute in the moved "m=" section and enable RTP/RTCP multiplexing attribute in the moved "m=" section and enable RTP/RTCP multiplexing
for the media associated with the "m=" section, or reject the "m=" for the media associated with the "m=" section, or reject the "m="
section [Section 7.3.4]. section [Section 7.3.3].
The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled
"m=" section in the answer. The answerer will use the port value of "m=" section in the answer. The answerer will use the port value of
the tagged offerer "m=" section sending RTP and RTCP packets the tagged offerer "m=" section sending RTP and RTCP packets
associated with RTP-based bundled media towards the offerer. associated with RTP-based bundled media towards the offerer.
If the usage of RTP/RTCP multiplexing within a BUNDLE group has been If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
negotiated in a previous offer/answer exchange, the answerer MUST negotiated in a previous offer/answer exchange, the answerer MUST
include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" include an SDP 'rtcp-mux' attribute in the answerer tagged "m="
section . It is not possible to disable RTP/RTCP multiplexing within section . It is not possible to disable RTP/RTCP multiplexing within
skipping to change at page 32, line 33 skipping to change at page 32, line 35
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 bundled "m=" section within transport, instead of per individual bundled "m=" section within
the BUNDLE group. the BUNDLE group.
o The generic SDP attribute offer/answer considerations o The generic SDP attribute offer/answer considerations
[Section 7.1.3] also apply to ICE-related attributes. Therefore, [Section 7.1.3] also apply to ICE-related attributes. Therefore,
when an offer sends an initial offer (in order to negotiate a when an offer sends an initial BUNDLE offer (in order to negotiate
BUNDLE group) the offerer include ICE-related media-level a BUNDLE group) the offerer include ICE-related media-level
attributes in each bundled "m=" section (excluding any bundle-only attributes in each bundled "m=" section (excluding any bundle-only
"m=" section), and each "m=" section MUST contain unique ICE "m=" section), and each "m=" section MUST contain unique ICE
properties. When an answerer generates an answer (initial or properties. When an answerer generates an answer (initial BUNDLE
subsequent) that contains a BUNDLE group, and when an offerer answer or subsequent) that contains a BUNDLE group, and when an
sends a subsequent offer that contains a BUNDLE group, ICE-related offerer sends a subsequent offer that contains a BUNDLE group,
media-level attributes are only included in the tagged "m=" ICE-related media-level attributes are only included in the tagged
section (suggested offerer tagged "m=" section or answerer tagged "m=" section (suggested offerer tagged "m=" section or answerer
"m=" section), and the ICE properties are applied to each bundled tagged "m=" section), and the ICE properties are applied to each
"m=" section within the BUNDLE group. bundled "m=" section within the BUNDLE group.
NOTE: Most ICE-related media-level SDP attributes belong to the NOTE: Most ICE-related media-level SDP attributes belong to the
TRANSPORT multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes], TRANSPORT multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes],
and the generic SDP attribute offer/answer considerations for and the generic SDP attribute offer/answer considerations for
TRANSPORT multiplexing category apply to the attributes. However, in TRANSPORT multiplexing category apply to the attributes. However, in
the case of ICE-related attributes, the same considerations also the case of ICE-related attributes, the same considerations also
apply to ICE-related media-level attributes that belong to other apply to ICE-related media-level attributes that belong to other
multiplexing categories. multiplexing categories.
NOTE: The following ICE-related media-level SDP attributes are NOTE: The following ICE-related media-level SDP attributes are
skipping to change at page 33, line 23 skipping to change at page 33, line 25
candidate pairs, they form the BUNDLE transport. candidate pairs, they form the BUNDLE 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, and the procedures in this section only apply when the is OPTIONAL, and the procedures in this section only apply when the
ICE mechanism is used. Note that applications might mandate usage of ICE mechanism is used. Note that applications might mandate usage of
the ICE mechanism even if the BUNDLE extension is not used. the ICE mechanism even if the BUNDLE extension is not used.
NOTE: If the trickle ICE mechanism [I-D.ietf-mmusic-trickle-ice-sip] NOTE: If the trickle ICE mechanism [I-D.ietf-mmusic-trickle-ice-sip]
is used, an offerer and answerer might assign a port value of '9', is used, an offerer and answerer might assign a port value of '9',
and an IPv4 address of '0.0.0.0' (or, the IPv6 equivalent '::') to and an IPv4 address of '0.0.0.0' (or, the IPv6 equivalent '::') to
multiple bundled "m=" sections in the initial offer. The offerer and multiple bundled "m=" sections in the initial BUNDLE offer. The
answerer will follow the normal procedures for generating the offers offerer and answerer will follow the normal procedures for generating
and answers, including picking a bundled "m=" section as the the offers and answers, including picking a bundled "m=" section as
suggested offerer tagged "m=" section, selecting the tagged "m=" the suggested offerer tagged "m=" section, selecting the tagged "m="
sections etc. The only difference is that media can not be sent sections etc. The only difference is that media can not be sent
until one or more candidates have been provided. Once a BUNDLE group until one or more candidates have been provided. Once a BUNDLE group
has been negotiated, trickled candidates associated with a bundled has been negotiated, trickled candidates associated with a bundled
"m=" section will be applied to all bundled "m=" sections within the "m=" section will be applied to all bundled "m=" sections within the
BUNDLE group. BUNDLE group.
11. DTLS Considerations 11. 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
skipping to change at page 41, line 15 skipping to change at page 41, line 31
for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can
provide the necessary security functions of ensuring the integrity provide the necessary security functions of ensuring the integrity
and source authenticity. and source authenticity.
17. Examples 17. Examples
17.1. Example: Tagged m= Section Selections 17.1. Example: Tagged m= Section Selections
The example below shows: The example below shows:
o An initial offer, in which the offerer wants to negotiate a BUNDLE o An initial BUNDLE offer, in which the offerer wants to negotiate a
group, and indicates the audio m= section as the suggested offerer BUNDLE group, and indicates the audio m= section as the suggested
tagged "m=" section. offerer tagged "m=" section.
o An initial answer, in which the answerer accepts the creation of o An initial BUNDLE answer, in which the answerer accepts the
the BUNDLE group, selects the audio m= section in the offer as the creation of the BUNDLE group, selects the audio m= section in the
offerer tagged "m=" section, selects the audio "m=" section in the offer as the offerer tagged "m=" section, selects the audio "m="
answer as the answerer tagged "m=" section and assigns the section in the answer as the answerer tagged "m=" section and
answerer BUNDLE address:port to that "m=" section. assigns the answerer BUNDLE address:port to that "m=" section.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 42, line 32 skipping to change at page 43, line 5
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only 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
17.2. Example: BUNDLE Group Rejected 17.2. Example: BUNDLE Group Rejected
The example below shows: The example below shows:
o An initial offer, in which the offerer wants to negotiate a BUNDLE o An initial BUNDLE offer, in which the offerer wants to negotiate a
group, and indicates the audio m= section as the suggested offerer BUNDLE group, and indicates the audio m= section as the suggested
tagged "m=" section. offerer tagged "m=" section.
o An initial answer, in which the answerer rejects the creation of o An initial BUNDLE answer, in which the answerer rejects the
the BUNDLE group, generates a normal answer and assigns a unique creation of the BUNDLE group, generates a normal answer and
address:port to each "m=" section in the answer. assigns a unique address:port to each "m=" section in the answer.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 49, line 41 skipping to change at page 50, line 41
Thanks to Linda Dunbar for performing the Gen-ART review. Thanks to Linda Dunbar for performing the Gen-ART review.
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.
19. Change Log 19. 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-51
o Changes based on IESG reviews.
o - Clarification of 'initial offer' terminology.
o - Merging of tagged m- section selection sections.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50
o Changes based on IESG reviews. o Changes based on IESG reviews.
o - Adding of tagged m- section concept. o - Adding of tagged m- section concept.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49
o Changes based on IESG reviews. o Changes based on IESG reviews.
 End of changes. 54 change blocks. 
145 lines changed or deleted 166 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/