draft-ietf-mmusic-sdp-simulcast-07.txt		draft-ietf-mmusic-sdp-simulcast-08.txt
	Network Working Group B. Burman		Network Working Group B. Burman
	Internet-Draft M. Westerlund		Internet-Draft M. Westerlund
	Intended status: Standards Track Ericsson		Intended status: Standards Track Ericsson
	Expires: August 4, 2017 S. Nandakumar		Expires: September 14, 2017 S. Nandakumar
	M. Zanaty		M. Zanaty
	Cisco		Cisco
	January 31, 2017		March 13, 2017
	Using Simulcast in SDP and RTP Sessions		Using Simulcast in SDP and RTP Sessions
	draft-ietf-mmusic-sdp-simulcast-07		draft-ietf-mmusic-sdp-simulcast-08
	Abstract		Abstract
	In some application scenarios it may be desirable to send multiple		In some application scenarios it may be desirable to send multiple
	differently encoded versions of the same media source in different		differently encoded versions of the same media source in different
	RTP streams. This is called simulcast. This document describes how		RTP streams. This is called simulcast. This document describes how
	to accomplish simulcast in RTP and how to signal it in SDP. The		to accomplish simulcast in RTP and how to signal it in SDP. The
	described solution uses an RTP/RTCP identification method to identify		described solution uses an RTP/RTCP identification method to identify
	RTP streams belonging to the same media source, and makes an		RTP streams belonging to the same media source, and makes an
	extension to SDP to relate those RTP streams as being different		extension to SDP to relate those RTP streams as being different
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 4, 2017.		This Internet-Draft will expire on September 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 5		3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 6
	3.2. Application Specific Media Source Handling . . . . . . . 7		3.2. Application Specific Media Source Handling . . . . . . . 7
	3.3. Receiver Media Source Preferences . . . . . . . . . . . . 7		3.3. Receiver Media Source Preferences . . . . . . . . . . . . 7
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Detailed Description . . . . . . . . . . . . . . . . . . . . 9		6. Detailed Description . . . . . . . . . . . . . . . . . . . . 10
	6.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10		6.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10
	6.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11		6.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11
	6.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 14		6.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 14
	6.3.1. Generating the Initial SDP Offer . . . . . . . . . . 14		6.3.1. Generating the Initial SDP Offer . . . . . . . . . . 14
	6.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 14		6.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 14
	6.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 15		6.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 15
	6.3.4. Modifying the Session . . . . . . . . . . . . . . . . 15		6.3.4. Modifying the Session . . . . . . . . . . . . . . . . 16
	6.4. Use with Declarative SDP . . . . . . . . . . . . . . . . 16		6.4. Use with Declarative SDP . . . . . . . . . . . . . . . . 16
	6.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 16		6.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 16
	6.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16		6.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 17
	6.6.1. Single-Source Client . . . . . . . . . . . . . . . . 17		6.6.1. Single-Source Client . . . . . . . . . . . . . . . . 17
	6.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18		6.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18
	7. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 21		7. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.1. Outgoing from Endpoint with Media Source . . . . . . . . 21		7.1. Outgoing from Endpoint with Media Source . . . . . . . . 21
	7.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 21		7.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 21
	7.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 23		7.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 23
	7.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 24		7.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 24
	7.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 25		7.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 25
	8. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 26		8. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 26
	8.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 26		8.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 26
	9. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 26		9. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 26
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 28		11. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28		12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
	14.1. Normative References . . . . . . . . . . . . . . . . . . 28		14.1. Normative References . . . . . . . . . . . . . . . . . . 28
	14.2. Informative References . . . . . . . . . . . . . . . . . 29		14.2. Informative References . . . . . . . . . . . . . . . . . 29
	Appendix A. Changes From Earlier Versions . . . . . . . . . . . 32		Appendix A. Changes From Earlier Versions . . . . . . . . . . . 32
	A.1. Modifications Between WG Version -05 and -06 . . . . . . 32		A.1. Modifications Between WG Version -07 and -08 . . . . . . 32
	A.2. Modifications Between WG Version -04 and -05 . . . . . . 32		A.2. Modifications Between WG Version -06 and -07 . . . . . . 32
	A.3. Modifications Between WG Version -03 and -04 . . . . . . 33		A.3. Modifications Between WG Version -05 and -06 . . . . . . 32
	A.4. Modifications Between WG Version -02 and -03 . . . . . . 33		A.4. Modifications Between WG Version -04 and -05 . . . . . . 33
	A.5. Modifications Between WG Version -01 and -02 . . . . . . 33		A.5. Modifications Between WG Version -03 and -04 . . . . . . 33
	A.6. Modifications Between WG Version -00 and -01 . . . . . . 34		A.6. Modifications Between WG Version -02 and -03 . . . . . . 34
	A.7. Modifications Between Individual Version -00 and WG		A.7. Modifications Between WG Version -01 and -02 . . . . . . 34
			A.8. Modifications Between WG Version -00 and -01 . . . . . . 34
			A.9. Modifications Between Individual Version -00 and WG
	Version -00 . . . . . . . . . . . . . . . . . . . . . . . 34		Version -00 . . . . . . . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	Most of today's multiparty video conference solutions make use of		Most of today's multiparty video conference solutions make use of
	centralized servers to reduce the bandwidth and CPU consumption in		centralized servers to reduce the bandwidth and CPU consumption in
	the endpoints. Those servers receive RTP streams from each		the endpoints. Those servers receive RTP streams from each
	participant and send some suitable set of possibly modified RTP		participant and send some suitable set of possibly modified RTP
	streams to the rest of the participants, which usually have		streams to the rest of the participants, which usually have
	skipping to change at page 10, line 9 ¶		skipping to change at page 10, line 20 ¶
	6. Detailed Description		6. Detailed Description
	This section further details the overview above (Section 5). First,		This section further details the overview above (Section 5). First,
	formal syntax is provided (Section 6.1), followed by the rest of the		formal syntax is provided (Section 6.1), followed by the rest of the
	SDP attribute definition in Section 6.2. Relating Simulcast Streams		SDP attribute definition in Section 6.2. Relating Simulcast Streams
	(Section 6.5) provides the definition of the RTP/RTCP mechanisms		(Section 6.5) provides the definition of the RTP/RTCP mechanisms
	used. The section is concluded with a number of examples.		used. The section is concluded with a number of examples.
	6.1. Simulcast Attribute		6.1. Simulcast Attribute
	This document defines a new SDP media-level "a=simulcast" attribute		This document defines a new SDP media-level "a=simulcast" attribute,
	with the following ABNF [RFC5234] syntax:		with value according to the following ABNF [RFC5234] syntax:
	sc-attr = "a=simulcast:" sc-value		sc-value = ( sc-send [SP sc-recv] ) / ( sc-recv [SP sc-send] )
	sc-value = sc-str-list [SP sc-str-list]		sc-send = "send" SP sc-str-list
	sc-str-list = sc-dir SP sc-alt-list *( ";" sc-alt-list )		sc-recv = "recv" SP sc-str-list
	sc-dir = "send" / "recv"		sc-str-list = sc-alt-list *( ";" sc-alt-list )
	sc-alt-list = sc-id *( "," sc-id )		sc-alt-list = sc-id *( "," sc-id )
	sc-id-paused = "~"		sc-id-paused = "~"
	sc-id = [sc-id-paused] rid-identifier		sc-id = [sc-id-paused] rid-id
	; SP defined in [RFC5234]		; SP defined in [RFC5234]
	; rid-identifier defined in [I-D.ietf-mmusic-rid]		; rid-id defined in [I-D.ietf-mmusic-rid]
	Figure 1: ABNF for Simulcast		Figure 1: ABNF for Simulcast Value
	The "a=simulcast" attribute has a parameter in the form of one or two		The "a=simulcast" attribute has a parameter in the form of one or two
	simulcast stream descriptions, each consisting of a direction ("send"		simulcast stream descriptions, each consisting of a direction ("send"
	or "recv"), followed by a list of one or more simulcast streams.		or "recv"), followed by a list of one or more simulcast streams.
	Each simulcast stream consists of one or more alternative simulcast		Each simulcast stream consists of one or more alternative simulcast
	formats. Each simulcast format is identified by a simulcast stream		formats. Each simulcast format is identified by a simulcast stream
	identifier (SCID). The SCID MUST have the form of an RTP stream		identifier (SCID). The SCID MUST have the form of an RTP stream
	identifier, as described by RTP Payload Format Restrictions		identifier, as described by RTP Payload Format Restrictions
	[I-D.ietf-mmusic-rid].		[I-D.ietf-mmusic-rid].
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 11 ¶
	reason to allow separate initial pause states for each SCID is that		reason to allow separate initial pause states for each SCID is that
	pause capability can be specified individually for each RTP payload		pause capability can be specified individually for each RTP payload
	type referenced by an SCID. Since pause capability specified via the		type referenced by an SCID. Since pause capability specified via the
	"a=rtcp-fb" attribute and SCID specified by "a=rid" can refer to		"a=rtcp-fb" attribute and SCID specified by "a=rid" can refer to
	common payload types, it is unfeasible to pause streams with SCID		common payload types, it is unfeasible to pause streams with SCID
	where any of the related RTP payload type(s) do not have pause		where any of the related RTP payload type(s) do not have pause
	capability.		capability.
	Examples:		Examples:
	a=simulcast:send 1,2,3;~4,~5 recv 6;~7,~8		a=simulcast:send 1,2,3;~4,~5 recv 6;~7,~8
	a=simulcast:recv 1;4,5 send 6;7		a=simulcast:recv 1;4,5 send 6;7
	Figure 2: Simulcast Examples		Figure 2: Simulcast Examples
	Above are two examples of different "a=simulcast" lines.		Above are two examples of different "a=simulcast" lines.
	The first line is an example offer to send two simulcast streams and		The first line is an example offer to send two simulcast streams and
	to receive two simulcast streams. The first simulcast stream in send		to receive two simulcast streams. The first simulcast stream in send
	direction can be sent in three different alternative formats (SCID 1,		direction can be sent in three different alternative formats (SCID 1,
	2, 3), and the second simulcast stream in send direction can be sent		2, 3), and the second simulcast stream in send direction can be sent
	in two different alternative formats (SCID 4, 5). Both of the second		in two different alternative formats (SCID 4, 5). Both of the second
	skipping to change at page 17, line 40 ¶		skipping to change at page 17, line 45 ¶
	c=IN IP4 192.0.2.156		c=IN IP4 192.0.2.156
	m=audio 49200 RTP/AVP 0		m=audio 49200 RTP/AVP 0
	a=rtpmap:0 PCMU/8000		a=rtpmap:0 PCMU/8000
	m=video 49300 RTP/AVP 97 98		m=video 49300 RTP/AVP 97 98
	a=rtpmap:97 H264/90000		a=rtpmap:97 H264/90000
	a=rtpmap:98 H264/90000		a=rtpmap:98 H264/90000
	a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000		a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000
	a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600		a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600
	a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720]		a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720]
	a=imageattr:98 send [x=320,y=180] recv [x=320,y=180]		a=imageattr:98 send [x=320,y=180] recv [x=320,y=180]
	a=rid:1 pt=97 send		a=rid:1 send pt=97
	a=rid:2 pt=98 send		a=rid:2 send pt=98
	a=rid:3 pt=97 recv		a=rid:3 recv pt=97
	a=simulcast:send 1;2 recv 3		a=simulcast:send 1;2 recv 3
	a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId		a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId
	Figure 4: Single-Source Simulcast Offer		Figure 4: Single-Source Simulcast Offer
	The only thing in the SDP that indicates simulcast capability is the		The only thing in the SDP that indicates simulcast capability is the
	line in the video media description containing the "simulcast"		line in the video media description containing the "simulcast"
	attribute. The included "a=fmtp" and "a=imageattr" parameters		attribute. The included "a=fmtp" and "a=imageattr" parameters
	indicates that sent simulcast streams can differ in video resolution.		indicates that sent simulcast streams can differ in video resolution.
	The RTP header extension for RtpStreamId is offered to avoid issues		The RTP header extension for RtpStreamId is offered to avoid issues
	with the initial binding between RTP streams (SSRCs) and the		with the initial binding between RTP streams (SSRCs) and the
	RtpStreamId identifying the simulcast stream and its format.		RtpStreamId identifying the simulcast stream and its format.
	The Answer from the server indicates that it too is simulcast		The Answer from the server indicates that it too is simulcast
	capable. Should it not have been simulcast capable, the		capable. Should it not have been simulcast capable, the
	"a=simulcast" line would not have been present and communication		"a=simulcast" line would not have been present and communication
	would have started with the media negotiated in the SDP. Also the		would have started with the media negotiated in the SDP. Also the
	usage of the RtpStreamId RTP header extension is accepted.		usage of the RtpStreamId RTP header extension is accepted.
	skipping to change at page 18, line 29 ¶		skipping to change at page 18, line 33 ¶
	c=IN IP4 192.0.2.43		c=IN IP4 192.0.2.43
	m=audio 49672 RTP/AVP 0		m=audio 49672 RTP/AVP 0
	a=rtpmap:0 PCMU/8000		a=rtpmap:0 PCMU/8000
	m=video 49674 RTP/AVP 97 98		m=video 49674 RTP/AVP 97 98
	a=rtpmap:97 H264/90000		a=rtpmap:97 H264/90000
	a=rtpmap:98 H264/90000		a=rtpmap:98 H264/90000
	a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000		a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000
	a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600		a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600
	a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720]		a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720]
	a=imageattr:98 send [x=320,y=180] recv [x=320,y=180]		a=imageattr:98 send [x=320,y=180] recv [x=320,y=180]
	a=rid:1 pt=97 recv		a=rid:1 recv pt=97
	a=rid:2 pt=98 recv		a=rid:2 recv pt=98
	a=rid:3 pt=97 send		a=rid:3 send pt=97
	a=simulcast:recv 1;2 send 3		a=simulcast:recv 1;2 send 3
	a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId		a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId
	Figure 5: Single-Source Simulcast Answer		Figure 5: Single-Source Simulcast Answer
	Since the server is the simulcast media receiver, it reverses the		Since the server is the simulcast media receiver, it reverses the
	direction of the "simulcast" and "rid" attribute parameters.		direction of the "simulcast" and "rid" attribute parameters.
	6.6.2. Multi-Source Client		6.6.2. Multi-Source Client
	skipping to change at page 26, line 16 ¶		skipping to change at page 26, line 16 ¶
	Simulcast is in this memo defined as the act of sending multiple		Simulcast is in this memo defined as the act of sending multiple
	alternative encoded streams of the same underlying media source.		alternative encoded streams of the same underlying media source.
	When transmitting multiple independent streams that originate from		When transmitting multiple independent streams that originate from
	the same source, it could potentially be done in several different		the same source, it could potentially be done in several different
	ways using RTP. A general discussion on considerations for use of		ways using RTP. A general discussion on considerations for use of
	the different RTP multiplexing alternatives can be found in		the different RTP multiplexing alternatives can be found in
	Guidelines for Multiplexing in RTP		Guidelines for Multiplexing in RTP
	[I-D.ietf-avtcore-multiplex-guidelines]. Discussion and		[I-D.ietf-avtcore-multiplex-guidelines]. Discussion and
	clarification on how to handle multiple streams in an RTP session can		clarification on how to handle multiple streams in an RTP session can
	be found in [I-D.ietf-avtcore-rtp-multi-stream].		be found in [RFC8108].
	The network aspects that are relevant for simulcast are:		The network aspects that are relevant for simulcast are:
	Quality of Service: When using simulcast it might be of interest to		Quality of Service: When using simulcast it might be of interest to
	prioritize a particular simulcast stream, rather than applying		prioritize a particular simulcast stream, rather than applying
	equal treatment to all streams. For example, lower bit-rate		equal treatment to all streams. For example, lower bit-rate
	streams may be prioritized over higher bit-rate streams to		streams may be prioritized over higher bit-rate streams to
	minimize congestion or packet losses in the low bit-rate streams.		minimize congestion or packet losses in the low bit-rate streams.
	Thus, there is a benefit to use a simulcast solution with good QoS		Thus, there is a benefit to use a simulcast solution with good QoS
	support.		support.
	skipping to change at page 27, line 39 ¶		skipping to change at page 27, line 39 ¶
	Contact name, email: IETF, contacted via mmusic@ietf.org, or a		Contact name, email: IETF, contacted via mmusic@ietf.org, or a
	successor address designated by IESG		successor address designated by IESG
	Attribute name: simulcast		Attribute name: simulcast
	Long-form attribute name: Simulcast stream description		Long-form attribute name: Simulcast stream description
	Charset dependent: No		Charset dependent: No
	Attribute value: See Section 6.1 of RFC XXXX.		Attribute value: sc-value; see Section 6.1 of RFC XXXX.
	Purpose: Signals simulcast capability for a set of RTP streams		Purpose: Signals simulcast capability for a set of RTP streams
	MUX category: NORMAL		MUX category: NORMAL
	Note to RFC Editor: Please replace "RFC XXXX" with the assigned		Note to RFC Editor: Please replace "RFC XXXX" with the assigned
	number of this RFC.		number of this RFC.
	11. Security Considerations		11. Security Considerations
	skipping to change at page 28, line 41 ¶		skipping to change at page 28, line 41 ¶
	Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have		Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have
	contributed with important material to the first versions of this		contributed with important material to the first versions of this
	document. Robert Hansen and Cullen Jennings, from Cisco, Peter		document. Robert Hansen and Cullen Jennings, from Cisco, Peter
	Thatcher, from Google, and Adam Roach, from Mozilla, contributed		Thatcher, from Google, and Adam Roach, from Mozilla, contributed
	significantly to subsequent versions.		significantly to subsequent versions.
	13. Acknowledgements		13. Acknowledgements
	The authors would like to thank Bernard Aboba, Thomas Belling, Roni		The authors would like to thank Bernard Aboba, Thomas Belling, Roni
	Even, and Adam Roach for the feedback they provided during the		Even, Adam Roach, Inaki Baz Castillo, and Paul Kyzivat for the
	development of this document.		feedback they provided during the development of this document.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[I-D.ietf-avtext-rid]		[I-D.ietf-avtext-rid]
	Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream		Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream
	Identifier Source Description (SDES)", draft-ietf-avtext-		Identifier Source Description (SDES)", draft-ietf-avtext-
	rid-09 (work in progress), October 2016.		rid-09 (work in progress), October 2016.
	[I-D.ietf-mmusic-rid]		[I-D.ietf-mmusic-rid]
	Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B.,		Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B.,
	Roach, A., and B. Campen, "RTP Payload Format		Roach, A., and B. Campen, "RTP Payload Format
	Restrictions", draft-ietf-mmusic-rid-08 (work in		Restrictions", draft-ietf-mmusic-rid-09 (work in
	progress), October 2016.		progress), February 2017.
	[I-D.ietf-mmusic-sdp-bundle-negotiation]		[I-D.ietf-mmusic-sdp-bundle-negotiation]
	Holmberg, C., Alvestrand, H., and C. Jennings,		Holmberg, C., Alvestrand, H., and C. Jennings,
	"Negotiating Media Multiplexing Using the Session		"Negotiating Media Multiplexing Using the Session
	Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-		Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
	negotiation-36 (work in progress), October 2016.		negotiation-36 (work in progress), October 2016.
	[I-D.ietf-mmusic-sdp-mux-attributes]		[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-16		Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
	skipping to change at page 30, line 5 ¶		skipping to change at page 30, line 5 ¶
	February 2016, <http://www.rfc-editor.org/info/rfc7728>.		February 2016, <http://www.rfc-editor.org/info/rfc7728>.
	14.2. Informative References		14.2. Informative References
	[I-D.ietf-avtcore-multiplex-guidelines]		[I-D.ietf-avtcore-multiplex-guidelines]
	Westerlund, M., Perkins, C., and H. Alvestrand,		Westerlund, M., Perkins, C., and H. Alvestrand,
	"Guidelines for using the Multiplexing Features of RTP to		"Guidelines for using the Multiplexing Features of RTP to
	Support Multiple Media Streams", draft-ietf-avtcore-		Support Multiple Media Streams", draft-ietf-avtcore-
	multiplex-guidelines-03 (work in progress), October 2014.		multiplex-guidelines-03 (work in progress), October 2014.
	[I-D.ietf-avtcore-rtp-multi-stream]
	Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
	"Sending Multiple RTP Streams in a Single RTP Session",
	draft-ietf-avtcore-rtp-multi-stream-11 (work in progress),
	December 2015.
	[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,		[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
	Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-		Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
	Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,		Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
	DOI 10.17487/RFC2198, September 1997,		DOI 10.17487/RFC2198, September 1997,
	<http://www.rfc-editor.org/info/rfc2198>.		<http://www.rfc-editor.org/info/rfc2198>.
	[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,		with Session Description Protocol (SDP)", RFC 3264,
	DOI 10.17487/RFC3264, June 2002,		DOI 10.17487/RFC3264, June 2002,
	<http://www.rfc-editor.org/info/rfc3264>.		<http://www.rfc-editor.org/info/rfc3264>.
	skipping to change at page 32, line 5 ¶		skipping to change at page 31, line 46 ¶
	[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,		[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
	DOI 10.17487/RFC7667, November 2015,		DOI 10.17487/RFC7667, November 2015,
	<http://www.rfc-editor.org/info/rfc7667>.		<http://www.rfc-editor.org/info/rfc7667>.
	[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F.		[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
	Galligan, "RTP Payload Format for VP8 Video", RFC 7741,		Galligan, "RTP Payload Format for VP8 Video", RFC 7741,
	DOI 10.17487/RFC7741, March 2016,		DOI 10.17487/RFC7741, March 2016,
	<http://www.rfc-editor.org/info/rfc7741>.		<http://www.rfc-editor.org/info/rfc7741>.
			[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
			"Sending Multiple RTP Streams in a Single RTP Session",
			RFC 8108, DOI 10.17487/RFC8108, March 2017,
			<http://www.rfc-editor.org/info/rfc8108>.
	Appendix A. Changes From Earlier Versions		Appendix A. Changes From Earlier Versions
	NOTE TO RFC EDITOR: Please remove this section prior to publication.		NOTE TO RFC EDITOR: Please remove this section prior to publication.
	A.1. Modifications Between WG Version -05 and -06		A.1. Modifications Between WG Version -07 and -08
			o Correcting syntax of SDP examples in section 6.6.1, as found by
			Inaki Baz Castillo.
			o Changing ABNF to only define the sc-value, not the SDP attribute
			itself, as suggested by Paul Kyzivat.
			o Changing I-D reference to newly published RFC 8108.
			o Adding list of modifications between -06 and -07.
			A.2. Modifications Between WG Version -06 and -07
			o A scope clarification, as result of the discussion with Roni Even.
			o A reformulation of the identification requirements for simulcast
			stream.
			o Correcting the statement related to source specific signalling
			(RFC 5576) to address Roni Even's comment.
			o Update of the last paragraph in Section 6.2 regarding simulcast
			stream differences as well as forbidding multiple instances of the
			same SCID within a single a=simulcast line.
			o Removal of note in Section 6.4 as result of issue raised by Roni
			Even.
			o Use of "m=" has been changed to media description and a few other
			editorial improvements and clarifications.
			A.3. Modifications Between WG Version -05 and -06
	o Added section on RTP Aspects		o Added section on RTP Aspects
	o Added a requirement (5-4) on that capability exchange must be		o Added a requirement (5-4) on that capability exchange must be
	capable of handling multi RTP stream cases.		capable of handling multi RTP stream cases.
	o Added extmap attribute also on first signalling example as it is a		o Added extmap attribute also on first signalling example as it is a
	recommended to use mechanism.		recommended to use mechanism.
	o Clarified the definition of the simulcast attribute and how		o Clarified the definition of the simulcast attribute and how
	simulcast streams relates to simulcast formats and SCIDs.		simulcast streams relates to simulcast formats and SCIDs.
	o Updated References list and moved around some references between		o Updated References list and moved around some references between
	informative and normative categories.		informative and normative categories.
	o Editorial improvements and corrections.		o Editorial improvements and corrections.
	A.2. Modifications Between WG Version -04 and -05		A.4. Modifications Between WG Version -04 and -05
	o Aligned with recent changes in draft-ietf-mmusic-rid and draft-		o Aligned with recent changes in draft-ietf-mmusic-rid and draft-
	ietf-avtext-rid.		ietf-avtext-rid.
	o Modified the SDP offer/answer section to follow the generally		o Modified the SDP offer/answer section to follow the generally
	accepted structure, also adding a brief text on modifying the		accepted structure, also adding a brief text on modifying the
	session that is aligned with draft-ietf-mmusic-rid.		session that is aligned with draft-ietf-mmusic-rid.
	o Improved text around simulcast stream identification (as opposed		o Improved text around simulcast stream identification (as opposed
	to the simulcast stream itself) to consistently use the acronym		to the simulcast stream itself) to consistently use the acronym
	skipping to change at page 33, line 5 ¶		skipping to change at page 33, line 33 ¶
	o Changed references for RTP-level pause/resume and VP8 payload		o Changed references for RTP-level pause/resume and VP8 payload
	format that are now published as RFC.		format that are now published as RFC.
	o Improved IANA registration text.		o Improved IANA registration text.
	o Removed unused reference to draft-ietf-payload-flexible-fec-		o Removed unused reference to draft-ietf-payload-flexible-fec-
	scheme.		scheme.
	o Editorial improvements and corrections.		o Editorial improvements and corrections.
	A.3. Modifications Between WG Version -03 and -04		A.5. Modifications Between WG Version -03 and -04
	o Changed to only use RID identification, as was consensus during		o Changed to only use RID identification, as was consensus during
	IETF 94.		IETF 94.
	o ABNF improvements.		o ABNF improvements.
	o Clarified offer-answer rules for initially paused streams.		o Clarified offer-answer rules for initially paused streams.
	o Changed references for RTP topologies and RTP taxonomy documents		o Changed references for RTP topologies and RTP taxonomy documents
	that are now published as RFC.		that are now published as RFC.
	o Added reference to the new RID draft in AVTEXT.		o Added reference to the new RID draft in AVTEXT.
	o Re-structured section 6 to provide an easy reference by the		o Re-structured section 6 to provide an easy reference by the
	updated IANA section.		updated IANA section.
	o Added a sub-section 7.1 with a discussion of bitrate adaptation.		o Added a sub-section 7.1 with a discussion of bitrate adaptation.
	o Editorial improvements.		o Editorial improvements.
	A.4. Modifications Between WG Version -02 and -03		A.6. Modifications Between WG Version -02 and -03
	o Removed text on multicast / broadcast from use cases, since it is		o Removed text on multicast / broadcast from use cases, since it is
	not supported by the solution.		not supported by the solution.
	o Removed explicit references to unified plan draft.		o Removed explicit references to unified plan draft.
	o Added possibility to initiate simulcast streams in paused mode.		o Added possibility to initiate simulcast streams in paused mode.
	o Enabled an offerer to offer multiple stream identification (pt or		o Enabled an offerer to offer multiple stream identification (pt or
	rid) methods and have the answerer choose which to use.		rid) methods and have the answerer choose which to use.
	o Added a preference indication also in send direction offers.		o Added a preference indication also in send direction offers.
	o Added a section on limitations of the current proposal, including		o Added a section on limitations of the current proposal, including
	identification method specific limitations.		identification method specific limitations.
	A.5. Modifications Between WG Version -01 and -02		A.7. Modifications Between WG Version -01 and -02
	o Relying on the new RID solution for codec constraints and		o Relying on the new RID solution for codec constraints and
	configuration identification. This has resulted in changes in		configuration identification. This has resulted in changes in
	syntax to identify if pt or RID is used to describe the simulcast		syntax to identify if pt or RID is used to describe the simulcast
	stream.		stream.
	o Renamed simulcast version and simulcast version alternative to		o Renamed simulcast version and simulcast version alternative to
	simulcast stream and simulcast format respectively, and improved		simulcast stream and simulcast format respectively, and improved
	definitions for them.		definitions for them.
	o Clarification that it is possible to switch between simulcast		o Clarification that it is possible to switch between simulcast
	version alternatives, but that only a single one be used at any		version alternatives, but that only a single one be used at any
	point in time.		point in time.
	o Changed the definition so that ordering of simulcast formats for a		o Changed the definition so that ordering of simulcast formats for a
	specific simulcast stream do have a preference order.		specific simulcast stream do have a preference order.
	A.6. Modifications Between WG Version -00 and -01		A.8. Modifications Between WG Version -00 and -01
	o No changes. Only preventing expiry.		o No changes. Only preventing expiry.
	A.7. Modifications Between Individual Version -00 and WG Version -00		A.9. Modifications Between Individual Version -00 and WG Version -00
	o Added this appendix.		o Added this appendix.
	Authors' Addresses		Authors' Addresses
	Bo Burman		Bo Burman
	Ericsson		Ericsson
	Gronlandsgatan 31		Gronlandsgatan 31
	SE-164 60 Stockholm		SE-164 60 Stockholm
	Sweden		Sweden
	Email: bo.burman@ericsson.com		Email: bo.burman@ericsson.com
	Magnus Westerlund		Magnus Westerlund
	Ericsson		Ericsson
End of changes. 31 change blocks.
	57 lines changed or deleted		88 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/