draft-ietf-rtcweb-jsep-22.txt		draft-ietf-rtcweb-jsep-23.txt
	Network Working Group J. Uberti		Network Working Group J. Uberti
	Internet-Draft Google		Internet-Draft Google
	Intended status: Standards Track C. Jennings		Intended status: Standards Track C. Jennings
	Expires: February 26, 2018 Cisco		Expires: March 5, 2018 Cisco
	E. Rescorla, Ed.		E. Rescorla, Ed.
	Mozilla		Mozilla
	August 25, 2017		September 1, 2017
	JavaScript Session Establishment Protocol		JavaScript Session Establishment Protocol
	draft-ietf-rtcweb-jsep-22		draft-ietf-rtcweb-jsep-23
	Abstract		Abstract
	This document describes the mechanisms for allowing a JavaScript		This document describes the mechanisms for allowing a JavaScript
	application to control the signaling plane of a multimedia session		application to control the signaling plane of a multimedia session
	via the interface specified in the W3C RTCPeerConnection API, and		via the interface specified in the W3C RTCPeerConnection API, and
	discusses how this relates to existing signaling protocols.		discusses how this relates to existing signaling protocols.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 February 26, 2018.		This Internet-Draft will expire on March 5, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12		3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12
	3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12		3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12
	3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12		3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12
	3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13		3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13
	3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 13		3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 13
	3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14		3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14
	3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15		3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15
	3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16		3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16
	3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 16		3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 16
	3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 17		3.6.2. Interpreting imageattr Attributes . . . . . . . . . . 17
	3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 18		3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 19
	3.8. Interactions With Forking . . . . . . . . . . . . . . . . 20		3.8. Interactions With Forking . . . . . . . . . . . . . . . . 20
	3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 20		3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 20
	3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 21		3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 21
	4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 21		4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 22		4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 22
	4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 22		4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 22
	4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 24		4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 24
	4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 24		4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 24
	4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 24		4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 24
	4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 25		4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 25
	4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 25		4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 25
	4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 26		4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 26
	4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 27		4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 27
	4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 27		4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 28
	4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 28		4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 28
	4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 29		4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 29
	4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 30		4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 29
	4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 30		4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 30
	4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 31		4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 30
	4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 31		4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 30
	4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 31		4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 30
	4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 31		4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 31
	4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 32		4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 31
	4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 33		4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 32
	4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 33		4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 33
	4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 33		4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 33
	4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 33		4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 33
	4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 34		4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 33
	4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 34		4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 33
	4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 34		4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 34
	4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 34		4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 34
	5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 35		5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 34
	5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 35		5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 34
	5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 35		5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 35
	5.1.2. Profile Names and Interoperability . . . . . . . . . 36		5.1.2. Profile Names and Interoperability . . . . . . . . . 35
	5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 37		5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 36
	5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 37		5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 36
	5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 44		5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 43
	5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47		5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47
	5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 48		5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 47
	5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 48		5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 47
	5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 49		5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 48
	5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 49		5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 48
	5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 55		5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 55
	5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 56		5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 56
	5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 57		5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 56
	5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 57		5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 56
	5.5. Processing a Local Description . . . . . . . . . . . . . 57		5.5. Processing a Local Description . . . . . . . . . . . . . 57
	5.6. Processing a Remote Description . . . . . . . . . . . . . 58		5.6. Processing a Remote Description . . . . . . . . . . . . . 58
	5.7. Parsing a Session Description . . . . . . . . . . . . . . 59		5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 58
	5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 59		5.8. Parsing a Session Description . . . . . . . . . . . . . . 59
	5.7.2. Media Section Parsing . . . . . . . . . . . . . . . . 61		5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 59
	5.7.3. Semantics Verification . . . . . . . . . . . . . . . 63		5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 61
	5.8. Applying a Local Description . . . . . . . . . . . . . . 65		5.8.3. Semantics Verification . . . . . . . . . . . . . . . 64
	5.9. Applying a Remote Description . . . . . . . . . . . . . . 66		5.9. Applying a Local Description . . . . . . . . . . . . . . 65
	5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 70		5.10. Applying a Remote Description . . . . . . . . . . . . . . 66
			5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 70
	6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 73		6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 73
	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 73		7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 73
	7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 73		7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 74
	7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 77		7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 78
	7.3. Early Transport Warmup Example . . . . . . . . . . . . . 87		7.3. Early Transport Warmup Example . . . . . . . . . . . . . 88
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 94		8. Security Considerations . . . . . . . . . . . . . . . . . . . 95
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 95		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
	11.1. Normative References . . . . . . . . . . . . . . . . . . 95		11.1. Normative References . . . . . . . . . . . . . . . . . . 96
	11.2. Informative References . . . . . . . . . . . . . . . . . 100		11.2. Informative References . . . . . . . . . . . . . . . . . 101
	Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 102		Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 103
	Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 103		Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 104
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114
	1. Introduction		1. Introduction
	This document describes how the W3C WEBRTC RTCPeerConnection		This document describes how the W3C WEBRTC RTCPeerConnection
	interface [W3C.webrtc] is used to control the setup, management and		interface [W3C.webrtc] is used to control the setup, management and
	teardown of a multimedia session.		teardown of a multimedia session.
	1.1. General Design of JSEP		1.1. General Design of JSEP
	WebRTC call setup has been designed to focus on controlling the media		WebRTC call setup has been designed to focus on controlling the media
	skipping to change at page 14, line 30 ¶		skipping to change at page 14, line 30 ¶
	The IceCandidate object also contains fields to indicate which m=		The IceCandidate object also contains fields to indicate which m=
	section it is associated with, which can be identified in one of two		section it is associated with, which can be identified in one of two
	ways, either by a m= section index, or a MID. The m= section index		ways, either by a m= section index, or a MID. The m= section index
	is a zero-based index, with index N referring to the N+1th m= section		is a zero-based index, with index N referring to the N+1th m= section
	in the session description referenced by this IceCandidate. The MID		in the session description referenced by this IceCandidate. The MID
	is a "media stream identification" value, as defined in [RFC5888],		is a "media stream identification" value, as defined in [RFC5888],
	Section 4, which provides a more robust way to identify the m=		Section 4, which provides a more robust way to identify the m=
	section in the session description, using the MID of the associated		section in the session description, using the MID of the associated
	RtpTransceiver object (which may have been locally generated by the		RtpTransceiver object (which may have been locally generated by the
	answerer when interacting with a non-JSEP endpoint that does not		answerer when interacting with a non-JSEP endpoint that does not
	support the MID attribute, as discussed in Section 5.9 below). If		support the MID attribute, as discussed in Section 5.10 below). If
	the MID field is present in a received IceCandidate, it MUST be used		the MID field is present in a received IceCandidate, it MUST be used
	for identification; otherwise, the m= section index is used instead.		for identification; otherwise, the m= section index is used instead.
	When creating an IceCandidate object, JSEP implementations MUST		When creating an IceCandidate object, JSEP implementations MUST
	populate each of the candidate, ufrag, m= section index, and MID		populate each of the candidate, ufrag, m= section index, and MID
	fields. Implementations MUST also be prepared to receive objects		fields. Implementations MUST also be prepared to receive objects
	with some fields missing, as mentioned above.		with some fields missing, as mentioned above.
	3.5.3. ICE Candidate Policy		3.5.3. ICE Candidate Policy
	skipping to change at page 17, line 25 ¶		skipping to change at page 17, line 25 ¶
	As an example, consider a system with a multiformat video decoder,		As an example, consider a system with a multiformat video decoder,
	which is capable of decoding any resolution from 48x48 to 720p, In		which is capable of decoding any resolution from 48x48 to 720p, In
	this case, the implementation would generate this attribute:		this case, the implementation would generate this attribute:
	a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0]		a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0]
	This declaration indicates that the receiver is capable of decoding		This declaration indicates that the receiver is capable of decoding
	any image resolution from 48x48 up to 1280x720 pixels.		any image resolution from 48x48 up to 1280x720 pixels.
	3.6.2. Interpreting an imageattr Attribute		3.6.2. Interpreting imageattr Attributes
	[RFC6236] defines "a=imageattr" to be an advisory field. This means		[RFC6236] defines "a=imageattr" to be an advisory field. This means
	that it does not absolutely constrain the video formats that the		that it does not absolutely constrain the video formats that the
	sender can use, but gives an indication of the preferred values.		sender can use, but gives an indication of the preferred values.
	This specification prescribes more specific behavior. When a		This specification prescribes more specific behavior. When a
	MediaStreamTrack, which is producing video of a certain resolution		MediaStreamTrack, which is producing video of a certain resolution
	(the "track resolution"), is attached to a RtpSender, which is		(the "track resolution"), is attached to a RtpSender, which is
	encoding the track video at the same or lower resolution(s) (the		encoding the track video at the same or lower resolution(s) (the
	"encoder resolutions"), and a remote description is applied that		"encoder resolutions"), and a remote description is applied that
	skipping to change at page 17, line 51 ¶		skipping to change at page 17, line 51 ¶
	cases in which the track changes its resolution, or is replaced with		cases in which the track changes its resolution, or is replaced with
	a different track.		a different track.
	Depending on how the RtpSender is configured, it may be producing a		Depending on how the RtpSender is configured, it may be producing a
	single encoding at a certain resolution, or, if simulcast Section 3.7		single encoding at a certain resolution, or, if simulcast Section 3.7
	has been negotiated, multiple encodings, each at their own specific		has been negotiated, multiple encodings, each at their own specific
	resolution. In addition, depending on the configuration, each		resolution. In addition, depending on the configuration, each
	encoding may have the flexibility to reduce resolution when needed,		encoding may have the flexibility to reduce resolution when needed,
	or may be locked to a specific output resolution.		or may be locked to a specific output resolution.
	For each encoding being produced by the RtpSender, the following		For each encoding being produced by the RtpSender, the set of
	rules are applied to determine what should be transmitted:		"a=imageattr recv" attributes in the corresponding m= section of the
			remote description is processed to determine what should be
			transmitted. Only attributes that reference the media format
			selected for the encoding are considered; each such attribute is
			evaluated individually, starting with the attribute with the highest
			"q=" value. If multiple attributes have the same "q=" value, they
			are evaluated in the order they appear in their containing m=
			section. Note that while JSEP endpoints will include at most one
			"a=imageattr recv" attribute per media format, JSEP endpoints may
			receive session descriptions from non-JSEP endpoints with m= sections
			that contain multiple such attributes.
	o First, the most suitable "a=imageattr recv" attribute is selected.		For each "a=imageattr recv" attribute, the following rules are
	This is performed by taking the attribute with the highest "q="		applied. If this processing is successful, the encoding is
	value from the set of attributes that reference the media format		transmitted accordingly, and no further attributes are considered for
	that has been selected for the specified encoding. If multiple		that encoding. Otherwise, the next attribute is evaluated, in the
	attributes have the same "q=" value, the one that appears first in		aforementioned order. If none of the supplied attributes can be
	the m= section is used. Note that while JSEP endpoints will		processed successfully, the encoding MUST NOT be transmitted, and an
	include at most one "a=imageattr recv" attribute per media format,		error SHOULD be raised to the application.
	JSEP endpoints may receive session descriptions from non-JSEP
	endpoints with m= sections that contain multiple such attributes.
	o If there is an applicable "a=imageattr recv" attribute for the		o The limits from the attribute are compared to the encoder
	encoding, the limits from the attribute are then compared to the		resolution. Only the specific limits mentioned below are
	encoder resolution. Only the specific limits mentioned below are
	considered; any other values, such as picture aspect ratio, MUST		considered; any other values, such as picture aspect ratio, MUST
	be ignored. When considering a MediaStreamTrack that is producing		be ignored. When considering a MediaStreamTrack that is producing
	rotated video, the unrotated resolution MUST be used for the		rotated video, the unrotated resolution MUST be used for the
	checks. This is required regardless of whether the receiver		checks. This is required regardless of whether the receiver
	supports performing receive-side rotation (e.g., through CVO		supports performing receive-side rotation (e.g., through CVO
	[TS26.114]), as it significantly simplifies the matching logic.		[TS26.114]), as it significantly simplifies the matching logic.
	o If the attribute includes a "sar=" (sample aspect ratio) value set		o If the attribute includes a "sar=" (sample aspect ratio) value set
	to something other than "1.0", indicating the receiver wants to		to something other than "1.0", indicating the receiver wants to
	receive non-square pixels, this cannot be satisfied and the sender		receive non-square pixels, this cannot be satisfied and the
	MUST NOT transmit the encoding.		attribute MUST NOT be used.
	o If the encoder resolution exceeds the maximum size permitted by		o If the encoder resolution exceeds the maximum size permitted by
	the attribute, and the encoder is allowed to adjust its		the attribute, and the encoder is allowed to adjust its
	resolution, the encoder SHOULD apply downscaling in order to		resolution, the encoder SHOULD apply downscaling in order to
	satisfy the limits, although the downscaling MUST NOT change the		satisfy the limits, although the downscaling MUST NOT change the
	picture aspect ratio of the encoding. For example, if the encoder		picture aspect ratio of the encoding. For example, if the encoder
	resolution is 1280x720, and the attribute specified a maximum of		resolution is 1280x720, and the attribute specified a maximum of
	640x480, the expected output resolution would be 640x360. If		640x480, the expected output resolution would be 640x360. If
	downscaling cannot be applied, the encoding MUST NOT be		downscaling cannot be applied, the attribute MUST NOT be used.
	transmitted, and an error SHOULD be raised to the application.
	o If the encoder resolution is less than the minimum size permitted		o If the encoder resolution is less than the minimum size permitted
	by the attribute, the encoding MUST NOT be transmitted, and an		by the attribute, the attribute MUST NOT be used; the encoder MUST
	error SHOULD be raised to the application; the encoder MUST NOT		NOT apply upscaling. JSEP implementations SHOULD avoid this
	apply upscaling. JSEP implementations SHOULD avoid this situation		situation by allowing receipt of arbitrarily small resolutions,
	by allowing receipt of arbitrarily small resolutions, perhaps via		perhaps via fallback to a software decoder.
	fallback to a software decoder.
			o If the encoder resolution is within the maximum and minimum sizes,
			no action is needed.
	3.7. Simulcast		3.7. Simulcast
	JSEP supports simulcast transmission of a MediaStreamTrack, where		JSEP supports simulcast transmission of a MediaStreamTrack, where
	multiple encodings of the source media can be transmitted within the		multiple encodings of the source media can be transmitted within the
	context of a single m= section. The current JSEP API is designed to		context of a single m= section. The current JSEP API is designed to
	allow applications to send simulcasted media but only to receive a		allow applications to send simulcasted media but only to receive a
	single encoding. This allows for multi-user scenarios where each		single encoding. This allows for multi-user scenarios where each
	sending client sends multiple encodings to a server, which then, for		sending client sends multiple encodings to a server, which then, for
	each receiving client, chooses the appropriate encoding to forward.		each receiving client, chooses the appropriate encoding to forward.
	skipping to change at page 28, line 48 ¶		skipping to change at page 29, line 6 ¶
	In certain situations it may be desirable to "undo" a change made to		In certain situations it may be desirable to "undo" a change made to
	setLocalDescription or setRemoteDescription. Consider a case where a		setLocalDescription or setRemoteDescription. Consider a case where a
	call is ongoing, and one side wants to change some of the session		call is ongoing, and one side wants to change some of the session
	parameters; that side generates an updated offer and then calls		parameters; that side generates an updated offer and then calls
	setLocalDescription. However, the remote side, either before or		setLocalDescription. However, the remote side, either before or
	after setRemoteDescription, decides it does not want to accept the		after setRemoteDescription, decides it does not want to accept the
	new parameters, and sends a reject message back to the offerer. Now,		new parameters, and sends a reject message back to the offerer. Now,
	the offerer, and possibly the answerer as well, need to return to a		the offerer, and possibly the answerer as well, need to return to a
	stable state and the previous local/remote description. To support		stable state and the previous local/remote description. To support
	this, we introduce the concept of "rollback".		this, we introduce the concept of "rollback", which discards any
			proposed changes to the session, returning the state machine to the
	A rollback discards any proposed changes to the session, returning		stable state. A rollback is performed by supplying a session
	the state machine to the stable state, and setting the pending local		description of type "rollback" with empty contents to either
	and/or remote description (see Section 4.1.12 and Section 4.1.14) to		setLocalDescription or setRemoteDescription.
	null. Any resources or candidates that were allocated by the
	abandoned local description are discarded; any media that is received
	will be processed according to the previous local and remote
	descriptions. Rollback can only be used to cancel proposed changes;
	there is no support for rolling back from a stable state to a
	previous stable state. Note that this implies that once the answerer
	has performed setLocalDescription with his answer, this cannot be
	rolled back.
	A rollback will disassociate any RtpTransceivers that were associated
	with m= sections by the application of the rolled-back session
	description (see Section 5.9 and Section 5.8). This means that some
	RtpTransceivers that were previously associated will no longer be
	associated with any m= section; in such cases, the value of the
	RtpTransceiver's mid property MUST be set to null, and the mapping
	between the transceiver and its m= section index MUST be discarded.
	RtpTransceivers that were created by applying a remote offer that was
	subsequently rolled back MUST be stopped and removed from the
	PeerConnection. However, a RtpTransceiver MUST NOT be removed if a
	track was attached to the RtpTransceiver via the addTrack method.
	This is so that an application may call addTrack, then call
	setRemoteDescription with an offer, then roll back that offer, then
	call createOffer and have a m= section for the added track appear in
	the generated offer.
	A rollback is performed by supplying a session description of type
	"rollback" with empty contents to either setLocalDescription or
	setRemoteDescription. The effect MUST be the same regardless of
	whether setLocalDescription or setRemoteDescription is called.
	A rollback may be performed if the PeerConnection is in any state
	except for "stable". This means that both offers and provisional
	answers can be rolled back. If a rollback is attempted in the
	"stable" state, processing MUST stop and an error MUST be returned.
	4.1.9. setLocalDescription		4.1.9. setLocalDescription
	The setLocalDescription method instructs the PeerConnection to apply		The setLocalDescription method instructs the PeerConnection to apply
	the supplied session description as its local configuration. The		the supplied session description as its local configuration. The
	type field indicates whether the description should be processed as		type field indicates whether the description should be processed as
	an offer, provisional answer, final answer, or rollback; offers and		an offer, provisional answer, final answer, or rollback; offers and
	answers are checked differently, using the various rules that exist		answers are checked differently, using the various rules that exist
	for each SDP line.		for each SDP line.
	skipping to change at page 38, line 34 ¶		skipping to change at page 38, line 4 ¶
	o An "a=ice-options" line with the "trickle" option MUST be added,		o An "a=ice-options" line with the "trickle" option MUST be added,
	as specified in [I-D.ietf-ice-trickle], Section 4.		as specified in [I-D.ietf-ice-trickle], Section 4.
	o If WebRTC identity is being used, an "a=identity" line as		o If WebRTC identity is being used, an "a=identity" line as
	described in [I-D.ietf-rtcweb-security-arch], Section 5.		described in [I-D.ietf-rtcweb-security-arch], Section 5.
	The next step is to generate m= sections, as specified in [RFC4566],		The next step is to generate m= sections, as specified in [RFC4566],
	Section 5.14. An m= section is generated for each RtpTransceiver		Section 5.14. An m= section is generated for each RtpTransceiver
	that has been added to the PeerConnection, excluding any stopped		that has been added to the PeerConnection, excluding any stopped
	RtpTransceivers. This is done in the order the RtpTransceivers were		RtpTransceivers; this is done in the order the RtpTransceivers were
	added to the PeerConnection.		added to the PeerConnection. If there are no such RtpTransceivers,
			no m= sections are generated; more can be added later, as discussed
			in [RFC3264], Section 5.
	For each m= section generated for an RtpTransceiver, establish a		For each m= section generated for an RtpTransceiver, establish a
	mapping between the transceiver and the index of the generated m=		mapping between the transceiver and the index of the generated m=
	section.		section.
	Each m= section, provided it is not marked as bundle-only, MUST		Each m= section, provided it is not marked as bundle-only, MUST
	generate a unique set of ICE credentials and gather its own unique		generate a unique set of ICE credentials and gather its own unique
	set of ICE candidates. Bundle-only m= sections MUST NOT contain any		set of ICE candidates. Bundle-only m= sections MUST NOT contain any
	ICE credentials and MUST NOT gather any candidates.		ICE credentials and MUST NOT gather any candidates.
	skipping to change at page 51, line 21 ¶		skipping to change at page 50, line 33 ¶
	a=recvonly		a=recvonly
	The Section 7.2 example later in this document shows a more involved		The Section 7.2 example later in this document shows a more involved
	case of "LS" group generation.		case of "LS" group generation.
	The next step is to generate m= sections for each m= section that is		The next step is to generate m= sections for each m= section that is
	present in the remote offer, as specified in [RFC3264], Section 6.		present in the remote offer, as specified in [RFC3264], Section 6.
	For the purposes of this discussion, any session-level attributes in		For the purposes of this discussion, any session-level attributes in
	the offer that are also valid as media-level attributes are		the offer that are also valid as media-level attributes are
	considered to be present in each m= section. Each offered m= section		considered to be present in each m= section. Each offered m= section
	will have an associated RtpTransceiver, as described in Section 5.9.		will have an associated RtpTransceiver, as described in Section 5.10.
	If there are more RtpTransceivers than there are m= sections, the		If there are more RtpTransceivers than there are m= sections, the
	unmatched RtpTransceivers will need to be associated in a subsequent		unmatched RtpTransceivers will need to be associated in a subsequent
	offer.		offer.
	For each offered m= section, if any of the following conditions are		For each offered m= section, if any of the following conditions are
	true, the corresponding m= section in the answer MUST be marked as		true, the corresponding m= section in the answer MUST be marked as
	rejected by setting the port in the m= line to zero, as indicated in		rejected by setting the port in the m= line to zero, as indicated in
	[RFC3264], Section 6, and further processing for this m= section can		[RFC3264], Section 6, and further processing for this m= section can
	be skipped:		be skipped:
	skipping to change at page 58, line 6 ¶		skipping to change at page 57, line 27 ¶
	assume that any implementation of this specification will be able to		assume that any implementation of this specification will be able to
	process, as a remote offer or answer, unmodified SDP coming from any		process, as a remote offer or answer, unmodified SDP coming from any
	other implementation of this specification.		other implementation of this specification.
	5.5. Processing a Local Description		5.5. Processing a Local Description
	When a SessionDescription is supplied to setLocalDescription, the		When a SessionDescription is supplied to setLocalDescription, the
	following steps MUST be performed:		following steps MUST be performed:
	o If the description is of type "rollback", follow the processing		o If the description is of type "rollback", follow the processing
	defined in Section 4.1.8.2 and skip the processing described in		defined in Section 5.7 and skip the processing described in the
	the rest of this section.		rest of this section.
	o Otherwise, the type of the SessionDescription is checked against		o Otherwise, the type of the SessionDescription is checked against
	the current state of the PeerConnection:		the current state of the PeerConnection:
	* If the type is "offer", the PeerConnection state MUST be either		* If the type is "offer", the PeerConnection state MUST be either
	"stable" or "have-local-offer".		"stable" or "have-local-offer".
	* If the type is "pranswer" or "answer", the PeerConnection state		* If the type is "pranswer" or "answer", the PeerConnection state
	MUST be either "have-remote-offer" or "have-local-pranswer".		MUST be either "have-remote-offer" or "have-local-pranswer".
	o If the type is not correct for the current state, processing MUST		o If the type is not correct for the current state, processing MUST
	stop and an error MUST be returned.		stop and an error MUST be returned.
	o The SessionDescription is then checked to ensure that its contents		o The SessionDescription is then checked to ensure that its contents
	are identical to those generated in the last call to createOffer/		are identical to those generated in the last call to createOffer/
	createAnswer, and thus have not been altered, as discussed in		createAnswer, and thus have not been altered, as discussed in
	Section 5.4; otherwise, processing MUST stop and an error MUST be		Section 5.4; otherwise, processing MUST stop and an error MUST be
	returned.		returned.
	o Next, the SessionDescription is parsed into a data structure, as		o Next, the SessionDescription is parsed into a data structure, as
	described in Section 5.7 below.		described in Section 5.8 below.
	o Finally, the parsed SessionDescription is applied as described in		o Finally, the parsed SessionDescription is applied as described in
	Section 5.8 below.		Section 5.9 below.
	5.6. Processing a Remote Description		5.6. Processing a Remote Description
	When a SessionDescription is supplied to setRemoteDescription, the		When a SessionDescription is supplied to setRemoteDescription, the
	following steps MUST be performed:		following steps MUST be performed:
	o If the description is of type "rollback", follow the processing		o If the description is of type "rollback", follow the processing
	defined in Section 4.1.8.2 and skip the processing described in		defined in Section 5.7 and skip the processing described in the
	the rest of this section.		rest of this section.
	o Otherwise, the type of the SessionDescription is checked against		o Otherwise, the type of the SessionDescription is checked against
	the current state of the PeerConnection:		the current state of the PeerConnection:
	* If the type is "offer", the PeerConnection state MUST be either		* If the type is "offer", the PeerConnection state MUST be either
	"stable" or "have-remote-offer".		"stable" or "have-remote-offer".
	* If the type is "pranswer" or "answer", the PeerConnection state		* If the type is "pranswer" or "answer", the PeerConnection state
	MUST be either "have-local-offer" or "have-remote-pranswer".		MUST be either "have-local-offer" or "have-remote-pranswer".
	o If the type is not correct for the current state, processing MUST		o If the type is not correct for the current state, processing MUST
	stop and an error MUST be returned.		stop and an error MUST be returned.
	o Next, the SessionDescription is parsed into a data structure, as		o Next, the SessionDescription is parsed into a data structure, as
	described in Section 5.7 below. If parsing fails for any reason,		described in Section 5.8 below. If parsing fails for any reason,
	processing MUST stop and an error MUST be returned.		processing MUST stop and an error MUST be returned.
	o Finally, the parsed SessionDescription is applied as described in		o Finally, the parsed SessionDescription is applied as described in
	Section 5.9 below.		Section 5.10 below.
	5.7. Parsing a Session Description		5.7. Processing a Rollback
			A rollback may be performed if the PeerConnection is in any state
			except for "stable". This means that both offers and provisional
			answers can be rolled back. Rollback can only be used to cancel
			proposed changes; there is no support for rolling back from a stable
			state to a previous stable state. If a rollback is attempted in the
			"stable" state, processing MUST stop and an error MUST be returned.
			Note that this implies that once the answerer has performed
			setLocalDescription with his answer, this cannot be rolled back.
			The effect of rollback MUST be the same regardless of whether
			setLocalDescription or setRemoteDescription is called.
			In order to process rollback, a JSEP implementation abandons the
			current offer/answer transaction, sets the signaling state to
			"stable", and sets the pending local and/or remote description (see
			Section 4.1.12 and Section 4.1.14) to null. Any resources or
			candidates that were allocated by the abandoned local description are
			discarded; any media that is received is processed according to the
			previous local and remote descriptions.
			A rollback disassociates any RtpTransceivers that were associated
			with m= sections by the application of the rolled-back session
			description (see Section 5.10 and Section 5.9). This means that some
			RtpTransceivers that were previously associated will no longer be
			associated with any m= section; in such cases, the value of the
			RtpTransceiver's mid property MUST be set to null, and the mapping
			between the transceiver and its m= section index MUST be discarded.
			RtpTransceivers that were created by applying a remote offer that was
			subsequently rolled back MUST be stopped and removed from the
			PeerConnection. However, a RtpTransceiver MUST NOT be removed if a
			track was attached to the RtpTransceiver via the addTrack method.
			This is so that an application may call addTrack, then call
			setRemoteDescription with an offer, then roll back that offer, then
			call createOffer and have a m= section for the added track appear in
			the generated offer.
			5.8. Parsing a Session Description
	The SDP contained in the session description object consists of a		The SDP contained in the session description object consists of a
	sequence of text lines, each containing a key-value expression, as		sequence of text lines, each containing a key-value expression, as
	described in [RFC4566], Section 5. The SDP is read, line-by-line,		described in [RFC4566], Section 5. The SDP is read, line-by-line,
	and converted to a data structure that contains the deserialized		and converted to a data structure that contains the deserialized
	information. However, SDP allows many types of lines, not all of		information. However, SDP allows many types of lines, not all of
	which are relevant to JSEP applications. For each line, the		which are relevant to JSEP applications. For each line, the
	implementation will first ensure it is syntactically correct		implementation will first ensure it is syntactically correct
	according to its defining ABNF, check that it conforms to [RFC4566]		according to its defining ABNF, check that it conforms to [RFC4566]
	and [RFC3264] semantics, and then either parse and store or discard		and [RFC3264] semantics, and then either parse and store or discard
	the provided value, as described below.		the provided value, as described below.
	If any line is not well-formed, or cannot be parsed as described, the		If any line is not well-formed, or cannot be parsed as described, the
	parser MUST stop with an error and reject the session description,		parser MUST stop with an error and reject the session description,
	even if the value is to be discarded. This ensures that		even if the value is to be discarded. This ensures that
	implementations do not accidentally misinterpret ambiguous SDP.		implementations do not accidentally misinterpret ambiguous SDP.
	5.7.1. Session-Level Parsing		5.8.1. Session-Level Parsing
	First, the session-level lines are checked and parsed. These lines		First, the session-level lines are checked and parsed. These lines
	MUST occur in a specific order, and with a specific syntax, as		MUST occur in a specific order, and with a specific syntax, as
	defined in [RFC4566], Section 5. Note that while the specific line		defined in [RFC4566], Section 5. Note that while the specific line
	types (e.g. "v=", "c=") MUST occur in the defined order, lines of the		types (e.g. "v=", "c=") MUST occur in the defined order, lines of the
	same type (typically "a=") can occur in any order.		same type (typically "a=") can occur in any order.
	The following non-attribute lines are not meaningful in the JSEP		The following non-attribute lines are not meaningful in the JSEP
	context and MAY be discarded once they have been checked.		context and MAY be discarded once they have been checked.
	skipping to change at page 61, line 13 ¶		skipping to change at page 61, line 24 ¶
	Section 5, and their values are stored.		Section 5, and their values are stored.
	Other attributes that are not relevant to JSEP may also be present,		Other attributes that are not relevant to JSEP may also be present,
	and implementations SHOULD process any that they recognize. As		and implementations SHOULD process any that they recognize. As
	required by [RFC4566], Section 5.13, unknown attribute lines MUST be		required by [RFC4566], Section 5.13, unknown attribute lines MUST be
	ignored.		ignored.
	Once all the session-level lines have been parsed, processing		Once all the session-level lines have been parsed, processing
	continues with the lines in m= sections.		continues with the lines in m= sections.
	5.7.2. Media Section Parsing		5.8.2. Media Section Parsing
	Like the session-level lines, the media section lines MUST occur in		Like the session-level lines, the media section lines MUST occur in
	the specific order and with the specific syntax defined in [RFC4566],		the specific order and with the specific syntax defined in [RFC4566],
	Section 5.		Section 5.
	The "m=" line itself MUST be parsed as described in [RFC4566],		The "m=" line itself MUST be parsed as described in [RFC4566],
	Section 5.14, and the media, port, proto, and fmt values stored.		Section 5.14, and the media, port, proto, and fmt values stored.
	Following the "m=" line, specific processing MUST be applied for the		Following the "m=" line, specific processing MUST be applied for the
	following non-attribute lines:		following non-attribute lines:
	skipping to change at page 63, line 42 ¶		skipping to change at page 64, line 5 ¶
	o If present, a single "a=max-message-size" attribute MUST be parsed		o If present, a single "a=max-message-size" attribute MUST be parsed
	as specified in [I-D.ietf-mmusic-sctp-sdp], Section 6, and the		as specified in [I-D.ietf-mmusic-sctp-sdp], Section 6, and the
	value stored. Otherwise, use the specified default.		value stored. Otherwise, use the specified default.
	Other attributes that are not relevant to JSEP may also be present,		Other attributes that are not relevant to JSEP may also be present,
	and implementations SHOULD process any that they recognize. As		and implementations SHOULD process any that they recognize. As
	required by [RFC4566], Section 5.13, unknown attribute lines MUST be		required by [RFC4566], Section 5.13, unknown attribute lines MUST be
	ignored.		ignored.
	5.7.3. Semantics Verification		5.8.3. Semantics Verification
	Assuming parsing completes successfully, the parsed description is		Assuming parsing completes successfully, the parsed description is
	then evaluated to ensure internal consistency as well as proper		then evaluated to ensure internal consistency as well as proper
	support for mandatory features. Specifically, the following checks		support for mandatory features. Specifically, the following checks
	are performed:		are performed:
	o For each m= section, valid values for each of the mandatory-to-use		o For each m= section, valid values for each of the mandatory-to-use
	features enumerated in Section 5.1.1 MUST be present. These		features enumerated in Section 5.1.1 MUST be present. These
	values MAY either be present at the media level, or inherited from		values MAY either be present at the media level, or inherited from
	the session level.		the session level.
	skipping to change at page 65, line 5 ¶		skipping to change at page 65, line 17 ¶
	m= sections MUST exactly match the number of m= sections in the		m= sections MUST exactly match the number of m= sections in the
	associated offer.		associated offer.
	o For each m= section, the media type and protocol values MUST		o For each m= section, the media type and protocol values MUST
	exactly match the media type and protocol values in the		exactly match the media type and protocol values in the
	corresponding m= section in the associated offer.		corresponding m= section in the associated offer.
	If any of the preceding checks failed, processing MUST stop and an		If any of the preceding checks failed, processing MUST stop and an
	error MUST be returned.		error MUST be returned.
	5.8. Applying a Local Description		5.9. Applying a Local Description
	The following steps are performed at the media engine level to apply		The following steps are performed at the media engine level to apply
	a local description. If an error is returned, the session MUST be		a local description. If an error is returned, the session MUST be
	restored to the state it was in before performing these steps.		restored to the state it was in before performing these steps.
	First, m= sections are processed. For each m= section, the following		First, m= sections are processed. For each m= section, the following
	steps MUST be performed; if any parameters are out of bounds, or		steps MUST be performed; if any parameters are out of bounds, or
	cannot be applied, processing MUST stop and an error MUST be		cannot be applied, processing MUST stop and an error MUST be
	returned.		returned.
	skipping to change at page 66, line 22 ¶		skipping to change at page 66, line 36 ¶
	[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2.		[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2.
	* For each specified "rtx" media format, establish a mapping		* For each specified "rtx" media format, establish a mapping
	between the RTX payload type and its associated primary payload		between the RTX payload type and its associated primary payload
	type, as described in [RFC4588], Sections 8.6 and 8.7.		type, as described in [RFC4588], Sections 8.6 and 8.7.
	* If the directional attribute is of type "sendrecv" or		* If the directional attribute is of type "sendrecv" or
	"recvonly", enable receipt and decoding of media.		"recvonly", enable receipt and decoding of media.
	Finally, if this description is of type "pranswer" or "answer",		Finally, if this description is of type "pranswer" or "answer",
	follow the processing defined in Section 5.10 below.		follow the processing defined in Section 5.11 below.
	5.9. Applying a Remote Description		5.10. Applying a Remote Description
	The following steps are performed to apply a remote description. If		The following steps are performed to apply a remote description. If
	an error is returned, the session MUST be restored to the state it		an error is returned, the session MUST be restored to the state it
	was in before performing these steps.		was in before performing these steps.
	If the answer contains any "a=ice-options" attributes where "trickle"		If the answer contains any "a=ice-options" attributes where "trickle"
	is listed as an attribute, update the PeerConnection canTrickle		is listed as an attribute, update the PeerConnection canTrickle
	property to be true. Otherwise, set this property to false.		property to be true. Otherwise, set this property to false.
	The following steps MUST be performed for attributes at the session		The following steps MUST be performed for attributes at the session
	skipping to change at page 70, line 13 ¶		skipping to change at page 70, line 32 ¶
	If there are any supported media formats that do not have a		If there are any supported media formats that do not have a
	corresponding telephone-event format, disable DTMF		corresponding telephone-event format, disable DTMF
	transmission for those formats.		transmission for those formats.
	+ For any specified "ptime" value, configure the available		+ For any specified "ptime" value, configure the available
	media formats to use the specified packet size when sending.		media formats to use the specified packet size when sending.
	If the specified size is not supported for a media format,		If the specified size is not supported for a media format,
	use the next closest value instead.		use the next closest value instead.
	Finally, if this description is of type "pranswer" or "answer",		Finally, if this description is of type "pranswer" or "answer",
	follow the processing defined in Section 5.10 below.		follow the processing defined in Section 5.11 below.
	5.10. Applying an Answer		5.11. Applying an Answer
	In addition to the steps mentioned above for processing a local or		In addition to the steps mentioned above for processing a local or
	remote description, the following steps are performed when processing		remote description, the following steps are performed when processing
	a description of type "pranswer" or "answer".		a description of type "pranswer" or "answer".
	For each m= section, the following steps MUST be performed:		For each m= section, the following steps MUST be performed:
	o If the m= section has been rejected (i.e. port is set to zero in		o If the m= section has been rejected (i.e. port is set to zero in
	the answer), stop any reception or transmission of media for this		the answer), stop any reception or transmission of media for this
	section, and, unless a non-rejected m= section is bundled with		section, and, unless a non-rejected m= section is bundled with
	skipping to change at page 96, line 13 ¶		skipping to change at page 97, line 13 ¶
	rid-09 (work in progress), October 2016.		rid-09 (work in progress), October 2016.
	[I-D.ietf-ice-trickle]		[I-D.ietf-ice-trickle]
	Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,		Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
	"Trickle ICE: Incremental Provisioning of Candidates for		"Trickle ICE: Incremental Provisioning of Candidates for
	the Interactive Connectivity Establishment (ICE)		the Interactive Connectivity Establishment (ICE)
	Protocol", draft-ietf-ice-trickle-13 (work in progress),		Protocol", draft-ietf-ice-trickle-13 (work in progress),
	July 2017.		July 2017.
	[I-D.ietf-mmusic-dtls-sdp]		[I-D.ietf-mmusic-dtls-sdp]
	Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer		Holmberg, C. and R. Shpount, "Session Description Protocol
	Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-28 (work		(SDP) Offer/Answer Considerations for Datagram Transport
	in progress), August 2017.		Layer Security (DTLS) and Transport Layer Security (TLS)",
			draft-ietf-mmusic-dtls-sdp-29 (work in progress), August
			2017.
	[I-D.ietf-mmusic-msid]		[I-D.ietf-mmusic-msid]
	Alvestrand, H., "WebRTC MediaStream Identification in the		Alvestrand, H., "WebRTC MediaStream Identification in the
	Session Description Protocol", draft-ietf-mmusic-msid-16		Session Description Protocol", draft-ietf-mmusic-msid-16
	(work in progress), February 2017.		(work in progress), February 2017.
	[I-D.ietf-mmusic-mux-exclusive]		[I-D.ietf-mmusic-mux-exclusive]
	Holmberg, C., "Indicating Exclusive Support of RTP/RTCP		Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
	Multiplexing using SDP", draft-ietf-mmusic-mux-		Multiplexing using SDP", draft-ietf-mmusic-mux-
	exclusive-12 (work in progress), May 2017.		exclusive-12 (work in progress), May 2017.
	skipping to change at page 96, line 45 ¶		skipping to change at page 97, line 47 ¶
	"Session Description Protocol (SDP) Offer/Answer		"Session Description Protocol (SDP) Offer/Answer
	Procedures For Stream Control Transmission Protocol (SCTP)		Procedures For Stream Control Transmission Protocol (SCTP)
	over Datagram Transport Layer Security (DTLS) Transport.",		over Datagram Transport Layer Security (DTLS) Transport.",
	draft-ietf-mmusic-sctp-sdp-26 (work in progress), April		draft-ietf-mmusic-sctp-sdp-26 (work in progress), April
	2017.		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-38 (work in progress), April 2017.		negotiation-39 (work in progress), August 2017.
	[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
	(work in progress), December 2016.		(work in progress), December 2016.
	[I-D.ietf-mmusic-sdp-simulcast]		[I-D.ietf-mmusic-sdp-simulcast]
	Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,		Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
	"Using Simulcast in SDP and RTP Sessions", draft-ietf-		"Using Simulcast in SDP and RTP Sessions", draft-ietf-
	mmusic-sdp-simulcast-10 (work in progress), July 2017.		mmusic-sdp-simulcast-10 (work in progress), July 2017.
	skipping to change at page 97, line 31 ¶		skipping to change at page 98, line 31 ¶
	[I-D.ietf-rtcweb-security]		[I-D.ietf-rtcweb-security]
	Rescorla, E., "Security Considerations for WebRTC", draft-		Rescorla, E., "Security Considerations for WebRTC", draft-
	ietf-rtcweb-security-08 (work in progress), February 2015.		ietf-rtcweb-security-08 (work in progress), February 2015.
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-12 (work in progress), June 2016.		rtcweb-security-arch-12 (work in progress), June 2016.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002, <https://www.rfc-		DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
	editor.org/info/rfc3261>.		editor.org/info/rfc3261>.
	[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, <https://www.rfc-		DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
	skipping to change at page 102, line 21 ¶		skipping to change at page 103, line 21 ¶
	[W3C.webrtc]		[W3C.webrtc]
	Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A.,		Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A.,
	Aboba, B., and T. Brandstetter, "WebRTC 1.0: Real-time		Aboba, B., and T. Brandstetter, "WebRTC 1.0: Real-time
	Communication Between Browsers", World Wide Web Consortium		Communication Between Browsers", World Wide Web Consortium
	WD WD-webrtc-20170515, May 2017,		WD WD-webrtc-20170515, May 2017,
	<https://www.w3.org/TR/2017/WD-webrtc-20170515/>.		<https://www.w3.org/TR/2017/WD-webrtc-20170515/>.
	Appendix A. Appendix A		Appendix A. Appendix A
	For the syntax validation performed in Section 5.7, the following		For the syntax validation performed in Section 5.8, the following
	list of ABNF definitions is used:		list of ABNF definitions is used:
	+------------------------+------------------------------------------+		+------------------------+------------------------------------------+
	| Attribute | Reference |		| Attribute | Reference |
	+------------------------+------------------------------------------+		+------------------------+------------------------------------------+
	| ptime | [RFC4566] Section 9 |		| ptime | [RFC4566] Section 9 |
	| maxptime | [RFC4566] Section 9 |		| maxptime | [RFC4566] Section 9 |
	| rtpmap | [RFC4566] Section 9 |		| rtpmap | [RFC4566] Section 9 |
	| recvonly | [RFC4566] Section 9 |		| recvonly | [RFC4566] Section 9 |
	| sendrecv | [RFC4566] Section 9 |		| sendrecv | [RFC4566] Section 9 |
	skipping to change at page 103, line 48 ¶		skipping to change at page 104, line 48 ¶
	| | 6.1 |		| | 6.1 |
	| tls-id | [I-D.ietf-mmusic-dtls-sdp] Section 4 |		| tls-id | [I-D.ietf-mmusic-dtls-sdp] Section 4 |
	+------------------------+------------------------------------------+		+------------------------+------------------------------------------+
	Table 1: SDP ABNF References		Table 1: SDP ABNF References
	Appendix B. Change log		Appendix B. Change log
	Note to RFC Editor: Please remove this section before publication.		Note to RFC Editor: Please remove this section before publication.
			Changes in draft-23:
			o Clarify rollback handling, and treat it similarly to other
			setLocal/setRemote usages.
			o Adopt a first-fit policy for handling multiple remote a=imageattr
			attributes.
			o Clarify that a session description with zero m= sections is legal.
	Changes in draft-22:		Changes in draft-22:
	o Clarify currentDirection versus direction.		o Clarify currentDirection versus direction.
	o Correct session-id text so that it aligns with RFC 3264.		o Correct session-id text so that it aligns with RFC 3264.
	o Clarify that generated ICE candidate objects must have all four		o Clarify that generated ICE candidate objects must have all four
	fields.		fields.
	o Make rollback work from any state besides stable and regardless of		o Make rollback work from any state besides stable and regardless of
End of changes. 48 change blocks.
	138 lines changed or deleted		165 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/