draft-ietf-mmusic-sdp-bundle-negotiation-26.txt   draft-ietf-mmusic-sdp-bundle-negotiation-27.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: August 19, 2016 C. Jennings Expires: August 27, 2016 C. Jennings
Cisco Cisco
February 16, 2016 February 24, 2016
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-26.txt draft-ietf-mmusic-sdp-bundle-negotiation-27.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single address:port combination (BUNDLE address) for receiving media, single address:port combination (BUNDLE address) for receiving media,
referred to as bundled media, associated with multiple SDP media referred to as bundled media, associated with multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2016. This Internet-Draft will expire on August 27, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 15 skipping to change at page 3, line 15
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 16 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 16
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17
10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18
10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18
10.2. Associating RTP/RTCP Packets With Correct SDP Media 10.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 19 Description . . . . . . . . . . . . . . . . . . . . . . 19
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22
11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 22 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23
11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 22 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24
11.2.5. Modifying the Session . . . . . . . . . . . . . . . 23 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 23 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 25
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25
13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 24 13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25
13.3. New text replacing section 5.1 (2nd paragraph) of RFC 13.3. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25
13.5. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.6. Original text of section 8.4 (6th paragraph) of RFC 3264 25 13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 26
13.5. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.6. Original text of section 8.4 (6th paragraph) of RFC 3264 26
13.7. New text replacing section 8.4 (6th paragraph) of RFC 13.7. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
14. RTP/RTCP extensions for identification-tag transport . . . . 26 14. RTP/RTCP extensions for identification-tag transport . . . . 27
14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26 14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 27
14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27 14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 28
14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 27 14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 29
15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 28 15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 29
15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 28 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29
15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 29 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 30
16. Security Considerations . . . . . . . . . . . . . . . . . . . 29 16. Security Considerations . . . . . . . . . . . . . . . . . . . 30
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 30 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.1. Example: Bundle Address Selection . . . . . . . . . . . 30 17.1. Example: Bundle Address Selection . . . . . . . . . . . 31
17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 32 17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 33
17.3. Example: Offerer Adds A Media Description To A BUNDLE 17.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 33 Group . . . . . . . . . . . . . . . . . . . . . . . . . 34
17.4. Example: Offerer Moves A Media Description Out Of A 17.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35
17.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 17.5. Example: Offerer Disables A Media Description Within A
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 37
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
20.1. Normative References . . . . . . . . . . . . . . . . . . 44 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39
20.2. Informative References . . . . . . . . . . . . . . . . . 46 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
Appendix A. Design Considerations . . . . . . . . . . . . . . . 46 20.1. Normative References . . . . . . . . . . . . . . . . . . 46
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 47 20.2. Informative References . . . . . . . . . . . . . . . . . 47
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 47 Appendix A. Design Considerations . . . . . . . . . . . . . . . 48
A.3. Usage of port number value zero . . . . . . . . . . . . . 49 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 49 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 49
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 50 A.3. Usage of port number value zero . . . . . . . . . . . . . 50
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 50 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 50
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 50 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 51
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This specification defines a way to use a single address:port This specification defines a way to use a single address:port
combination (BUNDLE address) for receiving media associated with combination (BUNDLE address) for receiving media associated with
multiple SDP media descriptions ("m=" lines). multiple SDP media descriptions ("m=" lines).
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension called 'BUNDLE'. The extension can be used with the extension called 'BUNDLE'. The extension can be used with the
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
skipping to change at page 4, line 46 skipping to change at page 4, line 46
negotiate the BUNDLE addresses, one for the offerer (offerer BUNDLE negotiate the BUNDLE addresses, one for the offerer (offerer BUNDLE
address) and one for the answerer (answerer BUNDLE address), to be address) and one for the answerer (answerer BUNDLE address), to be
used for receiving the bundled media associated with a BUNDLE group. used for receiving the bundled media associated with a BUNDLE group.
Once the offerer and the answerer have negotiated a BUNDLE group, Once the offerer and the answerer have negotiated a BUNDLE group,
they associate their respective BUNDLE address with each "m=" line in they associate their respective BUNDLE address with each "m=" line in
the BUNDLE group. The BUNDLE addresses are used to receive all media the BUNDLE group. The BUNDLE addresses are used to receive all media
associated with the BUNDLE group. associated with the BUNDLE group.
The use of a BUNDLE group and a BUNDLE address also allows the usage The use of a BUNDLE group and a BUNDLE address also allows the usage
of a single set of Interactive Connectivity Establishment (ICE) of a single set of Interactive Connectivity Establishment (ICE)
[RFC5245] candidates for multiple "m=" lines. [I-D.ietf-ice-rfc5245bis] candidates for multiple "m=" lines.
This specification also defines a new SDP attribute, 'bundle-only', This specification also defines a new SDP attribute, 'bundle-only',
which can be used to request that specific media is only used if kept which can be used to request that specific media is only used if kept
within a BUNDLE group. within a BUNDLE group.
As defined in RFC 4566 [RFC4566], the semantics of assigning the same As defined in RFC 4566 [RFC4566], the semantics of assigning the same
port value to multiple "m=" lines are undefined, and there is no port value to multiple "m=" lines are undefined, and there is no
grouping defined by such means. Instead, an explicit grouping grouping defined by such means. Instead, an explicit grouping
mechanism needs to be used to express the intended semantics. This mechanism needs to be used to express the intended semantics. This
specification provides such an extension. specification provides such an extension.
skipping to change at page 9, line 21 skipping to change at page 9, line 21
line MUST be 'IP4' or 'IP6'. The same value MUST be associated with line MUST be 'IP4' or 'IP6'. The same value MUST be associated with
each "m=" line. each "m=" line.
NOTE: Extensions to this specification can specify usage of the NOTE: Extensions to this specification can specify usage of the
BUNDLE mechanism for other nettype and addrtype values than the ones BUNDLE mechanism for other nettype and addrtype values than the ones
listed above. listed above.
7.3. Bandwidth (b=) 7.3. 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.mmusic-sdp-mux-attributes] for when associating the SDP in [I-D.ietf-mmusic-sdp-mux-attributes] for when associating the SDP
bandwidth (b=) line with bundled "m=" lines. bandwidth (b=) line with bundled "m=" lines.
7.4. Attributes (a=) 7.4. Attributes (a=)
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.mmusic-sdp-mux-attributes] for when associating SDP in [I-D.ietf-mmusic-sdp-mux-attributes] for when associating SDP
attributes with bundled "m=" lines. attributes with bundled "m=" lines.
8. SDP Offer/Answer Procedures 8. SDP Offer/Answer Procedures
8.1. General 8.1. General
This section describes the SDP Offer/Answer [RFC3264] procedures for: This section describes the SDP Offer/Answer [RFC3264] procedures for:
o Negotiating and creating of a BUNDLE group; and o Negotiating and creating of a BUNDLE group; and
skipping to change at page 10, line 12 skipping to change at page 10, line 12
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.
The procedures in this section are independent of the media type or The procedures in this section are independent of the media type or
"m=" line proto value represented by a bundled "m=" line. Section 10 "m=" line proto value represented by a bundled "m=" line. Section 10
defines additional considerations for RTP based media. Section 6 defines additional considerations for RTP based media. Section 6
defines additional considerations for the usage of the SDP 'bundle- defines additional considerations for the usage of the SDP 'bundle-
only' attribute. Section 11 defines additional considerations for only' attribute. Section 11 defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) [RFC5245] the usage of Interactive Connectivity Establishment (ICE)
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.2. Generating the Initial SDP Offer 8.2. Generating the Initial SDP Offer
8.2.1. General 8.2.1. General
When an offerer generates an initial offer, in order to create a When an offerer generates an initial offer, in order to create a
skipping to change at page 18, line 49 skipping to change at page 18, line 49
10.1.2. Payload Type (PT) Value Reuse 10.1.2. Payload Type (PT) Value Reuse
Multiple bundled "m=" lines might represent RTP based media. As all Multiple bundled "m=" lines might represent RTP based media. As all
RTP based media associated with a BUNDLE group belong to the same RTP RTP based media associated with a BUNDLE group belong to the same RTP
session, in order for a given payload type value to be used inside session, in order for a given payload type value to be used inside
more than one bundled "m=" line, all codecs associated with the more than one bundled "m=" line, all codecs associated with the
payload type number MUST share an identical codec configuration. payload type number MUST share an identical codec configuration.
This means that the codecs MUST share the same media type, encoding This means that the codecs MUST share the same media type, encoding
name, clock rate and any parameter that can affect the codec name, clock rate and any parameter that can affect the codec
configuration and packetization. [I-D.mmusic-sdp-mux-attributes] configuration and packetization.
lists SDP attributes, whose attribute values must be identical for [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
all codecs that use the same payload type value. attribute values must be identical for all codecs that use the same
payload type value.
10.2. Associating RTP/RTCP Packets With Correct SDP Media Description 10.2. Associating RTP/RTCP Packets With Correct SDP Media Description
There are multiple mechanisms that can be used by an endpoint in There are multiple mechanisms that can be used by an endpoint in
order to associate received RTP/RTCP packets with a bundled "m=" order to associate received RTP/RTCP packets with a bundled "m="
line. Such mechanisms include using the payload type value carried line. Such mechanisms include using the payload type value carried
inside the RTP packets, the SSRC values carried inside the RTP inside the RTP packets, the SSRC values carried inside the RTP
packets, and other "m=" line specific information carried inside the packets, and other "m=" line specific information carried inside the
RTP packets. RTP packets.
skipping to change at page 20, line 30 skipping to change at page 20, line 35
The procedures in this section only apply to RTP-based "m=" lines. The procedures in this section only apply to RTP-based "m=" lines.
10.3.2.2. Generating the Initial SDP Offer 10.3.2.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, the offerer MUST When an offerer generates an initial offer, the offerer MUST
associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled
RTP-based "m=" line (including any bundle-only "m=" line) in the RTP-based "m=" line (including any bundle-only "m=" line) in the
offer. offer.
If an offerer wants to indicate exclusive support of RTP/RTCP If an offerer wants to indicate exclusive support of RTP/RTCP
multiplexing [I-D.mmusic-mux-exclusive] for one or more "m=" lines multiplexing [I-D.ietf-mmusic-mux-exclusive] for one or more "m="
within the BUNDLE group, the offerer MUST associate an SDP 'rtcp-mux- lines within the BUNDLE group, the offerer MUST associate an SDP
exclusive' attribute with those "m=" lines. 'rtcp-mux-exclusive' attribute with those "m=" lines.
NOTE: The offerer might also associate an SDP 'rtcp' attribute NOTE: The offerer might also associate an SDP 'rtcp' attribute
[RFC3605] with a bundled "m=" line, excluding a bundle-only "m=" [RFC3605] with a bundled "m=" line, excluding a bundle-only "m="
line, in order to provide a fallback port for RTCP. However, the line, in order to provide a fallback port for RTCP. However, the
fallback port will only be used in case the answerer does not include fallback port will only be used in case the answerer does not include
the "m=" line in the BUNDLE group in the associated answer. the "m=" line in the BUNDLE group in the associated answer.
In the initial offer, the address:port combination for RTCP MUST be In the initial offer, the address:port combination for RTCP MUST be
unique in each bundled RTP-based "m=" line (excluding a 'bundle-only' unique in each bundled RTP-based "m=" line (excluding a 'bundle-only'
"m=" line), similar to RTP. "m=" line), similar to RTP.
skipping to change at page 22, line 13 skipping to change at page 22, line 23
(including any bundled "m=" line that the offerer wants to add to the (including any bundled "m=" line that the offerer wants to add to the
BUNDLE group), unless the offerer wants to disable or remove the "m=" BUNDLE group), unless the offerer wants to disable or remove the "m="
line from the BUNDLE group. line from the BUNDLE group.
11. ICE Considerations 11. ICE Considerations
11.1. General 11.1. General
This section describes how to use the BUNDLE grouping extension This section describes how to use the BUNDLE grouping extension
together with the Interactive Connectivity Establishment (ICE) together with the Interactive Connectivity Establishment (ICE)
mechanism [RFC5245]. mechanism [I-D.ietf-ice-rfc5245bis].
The procedures defined in [RFC5245] also apply to usage of ICE with The generic procedures for negotiating usage of ICE using SDP,
BUNDLE, with the following exception: defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE
with BUNDLE, with the following exceptions:
o When BUNDLE addresses for a BUNDLE group have been selected for o When BUNDLE addresses for a BUNDLE group have been selected for
both endpoints, ICE connectivity checks and keep-alives only need both endpoints, ICE connectivity checks and keep-alives only need
to be performed for the whole BUNDLE group, instead of per bundled to be performed for the whole BUNDLE group, instead of per bundled
"m=" line. "m=" line.
o Among bundled "m=" lines with which the offerer has associated a
shared address, the offerer only associates ICE-related media-
level SDP attributes with the "m=" line associated with the
offerer BUNDLE-tag.
o Among bundled "m=" lines with which the answerer has associated a
shared address, the answerer only associates ICE-related media-
level SDP attributes with the "m=" line associated with the
answerer BUNDLE-tag.
Support and usage of ICE mechanism together with the BUNDLE extension Support and usage of ICE mechanism together with the BUNDLE extension
is OPTIONAL. is OPTIONAL.
11.2. SDP Offer/Answer Procedures 11.2. SDP Offer/Answer Procedures
11.2.1. General 11.2.1. General
When an offerer associates a unique address with a bundled "m=" line When an offerer associates a unique address with a bundled "m=" line
(excluding any bundle-only "m=" line), it MUST also associate unique (excluding any bundle-only "m=" line), the offerer MUST associate SDP
ICE candidates [RFC5245] to the "m=" line. 'candidate' attributes (and other applicable ICE-related media-level
SDP attributes), containing unique ICE properties (candidates etc),
with the "m=" line, according to the procedures in
[I-D.ietf-mmusic-ice-sip-sdp].
An offerer MUST NOT associate ICE candidates with a bundle-only "m=" When an offerer associates a shared address with a bundled "m=" line,
line with a zero port value. if the "m=" line is associated with the offerer BUNDLE-tag, the
offerer MUST associate SDP 'candidate' attributes (and other
applicable ICE-related media-level SDP attributes), containing shared
ICE properties, with the "m=" line. If the "m=" line is not
associated with the offerer BUNDLE-tag, the offerer MUST NOT
associate ICE-related SDP attributes with the "m=" line.
NOTE: The bundle-only "m=" line, if accepted by the answerer, will When an answerer associates a shared address with a bundled "m="
inherit the candidates associated with the selected offerer BUNDLE line, if the "m=" line is associated with the answerer BUNDLE-tag,
address. An answerer that does not support BUNDLE would not accept a the answerer MUST associate SDP 'candidate' attributes (and other
bundle-only "m=" line. applicable ICE-related media-level SDP attributes), containing shared
ICE properties, with the "m=" line. If the "m=" line is not
associated with the answerer BUNDLE-tag, the answerer MUST NOT
associate ICE-related SDP attributes with the "m=" line.
When an offerer or answerer associates a shared address (i.e. a NOTE: As bundled "m=" lines associated with a shared address will
previously selected BUNDLE address) with one or more bundled "m=" share the same ICE properties, there is no need to associated ICE-
lines, it MUST associate identical ICE candidates (referred to as related media-level SDP attributes with each "m=" line.
shared ICE candidates) with each of those "m=" lines.
NOTE: The following ICE-related media-level SDP attributes are
defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote-
candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-
pacing'.
11.2.2. Generating the Initial SDP Offer 11.2.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, it associates unique ICE When an offerer generates an initial offer, the offerer MUST
candidates with the bundled "m=" lines, according to Section 11.2.1. associate ICE-related media-level SDP attributes with each bundled
"m=" line, according to [Section 11.2.1].
11.2.3. Generating the SDP Answer 11.2.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 answerer MUST associate shared ICE candidates with each bundled the answerer MUST associated ICE-related SDP attributes with the "m="
"m=" line (including "m=" lines that were indicated as bundle-only in line associated with the answerer BUNDLE-tag, according to
the associated offer) in the answer. [Section 11.2.1].
11.2.4. Offerer Processing of the SDP Answer 11.2.4. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer supports and uses When an offerer receives an answer, if the answerer supports and uses
the ICE mechanism and the BUNDLE extension, the offerer MUST the ICE mechanism and the BUNDLE extension, the offerer MUST
associate the same ICE candidates, associated with the "m=" line associate the ICE properties associated with the offerer BUNDLE
representing the offerer BUNDLE address (selected by the answerer), address, selected by the answerer [Section 8.3.2], with each bundled
with each bundled "m=" line. "m=" line.
11.2.5. Modifying the Session 11.2.5. Modifying the Session
When an offerer generates a subsequent offer, it associates unique or When an offerer generates a subsequent offer, it MUST associated
shared ICE candidates with the bundled "m=" lines, according to unique or shared ICE properties to one or more bundled "m=" lines,
(Section 11.2.1). according to [Section 11.2.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:
skipping to change at page 38, line 37 skipping to change at page 39, line 37
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.
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-25 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26
o - ICE considerations modified: ICE-related SDP attributes only
added to the bundled m- line representing the selected BUNDLE
address.
o - Reference to draft-ietf-mmusic-ice-sip-sdp added.
o - Reference to RFC 5245 replaced with reference to draft-ietf-ice-
rfc5245bis.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25
o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux
considerations. considerations.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24
o - Reference and procedures associated with exclusive RTP/RTCP mux o - Reference and procedures associated with exclusive RTP/RTCP mux
added added
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23
skipping to change at page 46, line 9 skipping to change at page 47, line 20
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>. <http://www.rfc-editor.org/info/rfc5888>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[I-D.mmusic-sdp-mux-attributes] [I-D.ietf-ice-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal", draft-ietf-ice-rfc5245bis-01
(work in progress), December 2015.
[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
(work in progress), January 2016. (work in progress), January 2016.
[I-D.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-01 (work in progress), February 2016. exclusive-03 (work in progress), February 2016.
[I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using
Interactive Connectivity Establishment (ICE) with Session
Description Protocol (SDP) offer/answer and Session
Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip-
sdp-07 (work in progress), October 2015.
20.2. Informative References 20.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, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
 End of changes. 36 change blocks. 
90 lines changed or deleted 140 lines changed or added

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