< draft-ietf-mmusic-sdp-bundle-negotiation-22.txt		draft-ietf-mmusic-sdp-bundle-negotiation-23.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: December 18, 2015 C. Jennings		Expires: January 21, 2016 C. Jennings
	Cisco		Cisco
	June 16, 2015		July 20, 2015
	Negotiating Media Multiplexing Using the Session Description Protocol		Negotiating Media Multiplexing Using the Session Description Protocol
	(SDP)		(SDP)
	draft-ietf-mmusic-sdp-bundle-negotiation-22.txt		draft-ietf-mmusic-sdp-bundle-negotiation-23.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 December 18, 2015.		This Internet-Draft will expire on January 21, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 23 ¶		skipping to change at page 3, line 23 ¶
	Description . . . . . . . . . . . . . . . . . . . . . . 18		Description . . . . . . . . . . . . . . . . . . . . . . 18
	10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19		10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19
	10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19		10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19
	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 . . . . . . . . . . . . . . 23		11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23
	11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23		11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23
	11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23		11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23
	11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23		11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23
	11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23		11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24
	11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24		11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24
	12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24		12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24
	13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24		13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24
	13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24		13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24
	13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25		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 . . . . . . . . . . . . . . . . . . . . . . . . . . 25		3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25		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		13.5. New text replacing section 8.2 (2nd paragraph) of RFC
	3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25		3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	13.6. Original text of section 8.4 (6th 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 26		3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	14. RTP/RTCP extensions for identification-tag transport . . . . 26		14. RTP/RTCP extensions for identification-tag transport . . . . 26
	14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26		14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26
	14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27		14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27
	14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28		14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28		15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28
	15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 29		15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 29
	15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29		15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29
	15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 29		15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 30
	16. Security Considerations . . . . . . . . . . . . . . . . . . . 30		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 . . . . . . . . . . . . . . . . . 44		20. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
	Appendix A. Design Considerations . . . . . . . . . . . . . . . 45		20.1. Normative References . . . . . . . . . . . . . . . . . . 45
	A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45		20.2. Informative References . . . . . . . . . . . . . . . . . 46
	A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 46		Appendix A. Design Considerations . . . . . . . . . . . . . . . 47
	A.3. Usage of port number value zero . . . . . . . . . . . . . 47		A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 47
	A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 48		A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 48
	A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 48		A.3. Usage of port number value zero . . . . . . . . . . . . . 49
	A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 48		A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 49
	A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 49		A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 50
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49		A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 50
			A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 50
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
	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 12, line 19 ¶		skipping to change at page 12, line 19 ¶
	but the "m=" line does not contain an SDP 'bundle-only' attribute, it		but the "m=" line does not contain an SDP 'bundle-only' attribute, it
	is an indication that the offerer wants to disable the "m=" line		is an indication that the offerer wants to disable the "m=" line
	[Section 8.5.5].		[Section 8.5.5].
	8.3.2. Answerer Selection of Offerer Bundle Address		8.3.2. Answerer Selection of Offerer Bundle Address
	In an offer, the address (unique or shared) assigned to the bundled		In an offer, the address (unique or shared) assigned to the bundled
	"m=" line associated with the offerer BUNDLE-tag indicates the		"m=" line associated with the offerer BUNDLE-tag indicates the
	address that the offerer suggests as the offerer BUNDLE address		address that the offerer suggests as the offerer BUNDLE address
	[Section 8.2.2]. The answerer MUST check whether that "m=" line		[Section 8.2.2]. The answerer MUST check whether that "m=" line
	fulfills the following criteria:		fulfils the following criteria:
	o The answerer will not move the "m=" line out of the BUNDLE group		o The answerer will not move the "m=" line out of the BUNDLE group
	[Section 8.3.4];		[Section 8.3.4];
	o The answerer will not reject the "m=" line [Section 8.3.5]; and		o The answerer will not reject the "m=" line [Section 8.3.5]; and
	o The "m=" line does not contain a zero port value.		o The "m=" line does not contain a zero port value.
	If all of the criteria above are fulfilled, the answerer MUST select		If all of the criteria above are fulfilled, the answerer MUST select
	the address associated with the "m=" line as the offerer BUNDLE		the address associated with the "m=" line as the offerer BUNDLE
	skipping to change at page 16, line 43 ¶		skipping to change at page 16, line 43 ¶
	line within a BUNDLE group.		line within a BUNDLE group.
	9. Protocol Identification		9. Protocol Identification
	9.1. General		9.1. General
	Each "m=" line within a BUNDLE group MUST use the same transport-		Each "m=" line within a BUNDLE group MUST use the same transport-
	layer protocol. If bundled "m=" lines use different protocols on top		layer protocol. If bundled "m=" lines use different protocols on top
	of the transport-layer protocol, there MUST exist a publicly		of the transport-layer protocol, there MUST exist a publicly
	available specification which describes a mechanism, for this		available specification which describes a mechanism, for this
	particular protocol combination, how to associate a received data		particular protocol combination, how to associate received data with
	with the correct protocol.		the correct protocol.
	In addition, if a received data can be associated with more than one		In addition, if received data can be associated with more than one
	bundled "m=" line, there MUST exist a publicly available		bundled "m=" line, there MUST exist a publicly available
	specification which describes a mechanism for associating the		specification which describes a mechanism for associating the
	received data with the correct "m=" line.		received data with the correct "m=" line.
	This document describes a mechanism to identify the protocol of		This document describes a mechanism to identify the protocol of
	received data among the STUN, DTLS and SRTP protocols (in any		received data among the STUN, DTLS and SRTP protocols (in any
	combination), when UDP is used as transport-layer protocol, but does		combination), when UDP is used as transport-layer protocol, but does
	not describe how to identify different protocols transported on DTLS.		not describe how to identify different protocols transported on DTLS.
	While the mechanism is generally applicable to other protocols and		While the mechanism is generally applicable to other protocols and
	transport-layers protocols, any such use requires further		transport-layers protocols, any such use requires further
	skipping to change at page 19, line 13 ¶		skipping to change at page 19, line 13 ¶
	(and sent) using single address:port combinations, the local		(and sent) using single address:port combinations, the local
	address:port combination cannot be used to associate received RTP		address:port combination cannot be used to associate received RTP
	packets with the correct "m=" line.		packets with the correct "m=" line.
	As described in [Section 10.1.2], the same payload type value might		As described in [Section 10.1.2], the same payload type value might
	be used inside RTP packets described by multiple "m=" lines. In such		be used inside RTP packets described by multiple "m=" lines. In such
	cases, the payload type value cannot be used to associate received		cases, the payload type value cannot be used to associate received
	RTP packets with the correct "m=" line.		RTP packets with the correct "m=" line.
	An offerer and answerer can inform each other which SSRC values they		An offerer and answerer can inform each other which SSRC values they
	will use or RTP and RTCP by using the SDP 'ssrc' attribute [RFC5576].		will use for RTP and RTCP by using the SDP 'ssrc' attribute
	To allow for proper association with this mechanism, the 'ssrc'		[RFC5576]. To allow for proper association with this mechanism, the
	attribute needs to be associated with each "m=" line that shares a		'ssrc' attribute needs to be associated with each "m=" line that
	payload type with any other "m=" line in the same bundle. As the		shares a payload type with any other "m=" line in the same bundle.
	SSRC values will be carried inside the RTP/RTCP packets, the offerer		As the SSRC values will be carried inside the RTP/RTCP packets, the
	and answerer can then use that information to associate received RTP		offerer and answerer can then use that information to associate
	packets with the correct "m=" line. However, an offerer will not		received RTP packets with the correct "m=" line. However, an offerer
	know which SSRC values the answerer will use until it has received		will not know which SSRC values the answerer will use until it has
	the answer providing that information. Due to this, before the		received the answer providing that information. Due to this, before
	offerer has received the answer, the offerer will not be able to		the offerer has received the answer, the offerer will not be able to
	associate received RTP/RTCP packets with the correct "m=" line using		associate received RTP/RTCP packets with the correct "m=" line using
	the SSRC values.		the SSRC values.
	In order for an offerer and answerer to always be able to associate		In order for an offerer and answerer to always be able to associate
	received RTP and RTCP packets with the correct "m=" line, an offerer		received RTP and RTCP packets with the correct "m=" line, an offerer
	and answerer using the BUNDLE extension MUST support the mechanism		and answerer using the BUNDLE extension MUST support the mechanism
	defined in Section 14, where the remote endpoint inserts the		defined in Section 14, where the remote endpoint inserts the
	identification-tag associated with an "m=" line in RTP and RTCP		identification-tag associated with an "m=" line in RTP and RTCP
	packets associated with that "m=" line.		packets associated with that "m=" line.
	10.3. RTP/RTCP Multiplexing		10.3. RTP/RTCP Multiplexing
	10.3.1. General		10.3.1. General
	When a BUNDLE group, which contains RTP based media, is created, the		When a BUNDLE group, which contains RTP based media, is created, the
	offerer and answerer MUST negotiate whether to enable RTP/RTCP		offerer and answerer MUST negotiate whether to enable RTP/RTCP
	multiplexing for the RTP based media associated with the BUNDLE group		multiplexing for the RTP based media associated with the BUNDLE group
	[RFC5761].		[RFC5761].
	If RTP/RTCP multiplexing is enabled, the same address:port		If RTP/RTCP multiplexing is enabled, the same address:port
	combination will be used for receiving (and sending) all RTP packets		combination will be used for sending all RTP packets and the RTCP
	and the RTCP packets associated with the BUNDLE group. Each endpoint		packets associated with the BUNDLE group. Each endpoint will send
	will send the packets towards the BUNDLE address of the other		the packets towards the BUNDLE address of the other endpoint. The
	endpoint.		same address:port combination MAY be used for receiving RTP packets
			and RTCP packets.
	If RTP/RTCP multiplexing is not enabled, separate address:port		If RTP/RTCP multiplexing is not enabled, separate address:port
	combinations will be used for receiving (and sending) the RTP packets		combinations will be used for sending the RTP packets and the RTCP
	and the RTCP packets. If the remote endpoint has associated an SDP		packets. The same address:port combinations MAY be used for
	'rtcp' attribute with the "m=" line associated with the BUNDLE-tag,		receiving RTP packets and RTCP packets. If the remote endpoint has
	the attribute value will be used for sending all RTCP packets		associated an SDP 'rtcp' attribute with the "m=" line associated with
	associated with the BUNDLE group towards that endpoint.		the BUNDLE-tag, the attribute value will be used for sending all RTCP
			packets associated with the BUNDLE group towards that endpoint.
	10.3.2. SDP Offer/Answer Procedures		10.3.2. SDP Offer/Answer Procedures
	10.3.2.1. General		10.3.2.1. General
	This section describes how an offerer and answerer can use the SDP		This section describes how an offerer and answerer can use the SDP
	'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605]		'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605]
	to negotiate usage of RTP/RTCP multiplexing for RTP based media		to negotiate usage of RTP/RTCP multiplexing for RTP based media
	associated with a BUNDLE group.		associated with a BUNDLE group.
	skipping to change at page 38, line 21 ¶		skipping to change at page 39, line 21 ¶
	is based on a similar alternatives proposed by Harald Alvestrand and		is based on a similar alternatives proposed by Harald Alvestrand and
	Cullen Jennings. The BUNDLE extension described in this document is		Cullen Jennings. The BUNDLE extension described in this document is
	based on the different alternative proposals, and text (e.g. SDP		based on the different alternative proposals, and text (e.g. SDP
	examples) have been borrowed (and, in some cases, modified) from		examples) have been borrowed (and, in some cases, modified) from
	those alternative proposals.		those alternative proposals.
	The SDP examples are also modified versions from the ones in the		The SDP examples are also modified versions from the ones in the
	Alvestrand proposal.		Alvestrand proposal.
	Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas		Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas
	Stach, Ari Keraenen, Adam Roach, Christian Groves, Roman Shpount,		Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount,
	Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and		Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and
	Justin Uberti for reading the text, and providing useful feedback.		Justin Uberti for reading the text, and providing useful feedback.
	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-22
			o - Correction of Ari's family name
			o - Editorial fixes based on comments from Thomas Stach
			o - RTP/RTCP correction based on comment from Magnus Westerlund
			o -- http://www.ietf.org/mail-archive/web/mmusic/current/
			msg14861.html
	Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21		Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21
	o - Correct based on comment from Paul Kyzivat		o - Correct based on comment from Paul Kyzivat
	o -- 'received packets' replaced with 'received data'		o -- 'received packets' replaced with 'received data'
	Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20		Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20
	o - Clarification based on comment from James Guballa		o - Clarification based on comment from James Guballa
	o - Clarification based on comment from Flemming Andreasen		o - Clarification based on comment from Flemming Andreasen
	Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19		Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19
	skipping to change at page 44, line 16 ¶		skipping to change at page 45, line 26 ¶
	o Added text about single versus multiple RTP Sessions.		o Added text about single versus multiple RTP Sessions.
	o Added reference to RFC 3550.		o Added reference to RFC 3550.
	20. References		20. References
	20.1. Normative References		20.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	with Session Description Protocol (SDP)", RFC 3264, June		with Session Description Protocol (SDP)", RFC 3264,
	2002.		DOI 10.17487/RFC3264, June 2002,
			<http://www.rfc-editor.org/info/rfc3264>.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, July 2006.		Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
			July 2006, <http://www.rfc-editor.org/info/rfc4566>.
	[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP		[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
	Header Extensions", RFC 5285, July 2008.		Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
			2008, <http://www.rfc-editor.org/info/rfc5285>.
	[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and		[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
	Control Packets on a Single Port", RFC 5761, April 2010.		Control Packets on a Single Port", RFC 5761,
			DOI 10.17487/RFC5761, April 2010,
			<http://www.rfc-editor.org/info/rfc5761>.
	[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description		[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
	Protocol (SDP) Grouping Framework", RFC 5888, June 2010.		Protocol (SDP) Grouping Framework", RFC 5888,
			DOI 10.17487/RFC5888, June 2010,
			<http://www.rfc-editor.org/info/rfc5888>.
	[I-D.mmusic-sdp-mux-attributes]		[I-D.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-08		Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-08
	(work in progress), January 2015.		(work in progress), January 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,
	June 2002.		DOI 10.17487/RFC3261, June 2002,
			<http://www.rfc-editor.org/info/rfc3261>.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, July 2003.		Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
			July 2003, <http://www.rfc-editor.org/info/rfc3550>.
	[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute		[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
	in Session Description Protocol (SDP)", RFC 3605, October		in Session Description Protocol (SDP)", RFC 3605,
	2003.		DOI 10.17487/RFC3605, October 2003,
			<http://www.rfc-editor.org/info/rfc3605>.
	[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session		[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
	Description Protocol (SDP) Security Descriptions for Media		Description Protocol (SDP) Security Descriptions for Media
	Streams", RFC 4568, July 2006.		Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
			<http://www.rfc-editor.org/info/rfc4568>.
	[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",		[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
	BCP 131, RFC 4961, July 2007.		BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
			<http://www.rfc-editor.org/info/rfc4961>.
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment		[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols", RFC 5245, April		Traversal for Offer/Answer Protocols", RFC 5245,
	2010.		DOI 10.17487/RFC5245, April 2010,
			<http://www.rfc-editor.org/info/rfc5245>.
	[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific		[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
	Media Attributes in the Session Description Protocol		Media Attributes in the Session Description Protocol
	(SDP)", RFC 5576, June 2009.		(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
			<http://www.rfc-editor.org/info/rfc5576>.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer		[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure		Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.		Real-time Transport Protocol (SRTP)", RFC 5764,
			DOI 10.17487/RFC5764, May 2010,
			<http://www.rfc-editor.org/info/rfc5764>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
			January 2012, <http://www.rfc-editor.org/info/rfc6347>.
	[RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple		[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
	Clock Rates in an RTP Session", RFC 7160, April 2014.		Clock Rates in an RTP Session", RFC 7160,
			DOI 10.17487/RFC7160, April 2014,
			<http://www.rfc-editor.org/info/rfc7160>.
	[I-D.ietf-mmusic-trickle-ice]		[I-D.ietf-mmusic-trickle-ice]
	Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:		Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
	Incremental Provisioning of Candidates for the Interactive		Incremental Provisioning of Candidates for the Interactive
	Connectivity Establishment (ICE) Protocol", draft-ietf-		Connectivity Establishment (ICE) Protocol", draft-ietf-
	mmusic-trickle-ice-02 (work in progress), January 2015.		mmusic-trickle-ice-02 (work in progress), January 2015.
	Appendix A. Design Considerations		Appendix A. Design Considerations
	A.1. General		A.1. General
End of changes. 36 change blocks.
	72 lines changed or deleted		105 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/