draft-ietf-rtcweb-jsep-16.txt		draft-ietf-rtcweb-jsep-17.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: March 24, 2017 Cisco		Expires: April 24, 2017 Cisco
	E. Rescorla, Ed.		E. Rescorla, Ed.
	Mozilla		Mozilla
	September 20, 2016		October 21, 2016
	Javascript Session Establishment Protocol		Javascript Session Establishment Protocol
	draft-ietf-rtcweb-jsep-16		draft-ietf-rtcweb-jsep-17
	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 March 24, 2017.		This Internet-Draft will expire on April 24, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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 . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4		1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4
	1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5		1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6		3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6
	3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6		3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Session Descriptions and State Machine . . . . . . . . . 7		3.2. Session Descriptions and State Machine . . . . . . . . . 7
	3.3. Session Description Format . . . . . . . . . . . . . . . 10		3.3. Session Description Format . . . . . . . . . . . . . . . 10
	3.4. Session Description Control . . . . . . . . . . . . . . . 10		3.4. Session Description Control . . . . . . . . . . . . . . . 10
	3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 10		3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 10
	3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 11		3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 11
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 13		3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 13
	3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 14		3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 14
	3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 14		3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 14
	3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 15		3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 15
	3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 16		3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 16
	3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 17		3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 17
	3.8. Interactions With Forking . . . . . . . . . . . . . . . . 18		3.8. Interactions With Forking . . . . . . . . . . . . . . . . 18
	3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 18		3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 18
	3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 19		3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 19
	4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20		4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 20		4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 20
	4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 20		4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 20
	4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 22		4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 22
	4.1.3. addTransceiver . . . . . . . . . . . . . . . . . . . 22		4.1.3. addTransceiver . . . . . . . . . . . . . . . . . . . 22
	4.1.4. createDataChannel . . . . . . . . . . . . . . . . . . 22		4.1.4. createDataChannel . . . . . . . . . . . . . . . . . . 23
	4.1.5. createOffer . . . . . . . . . . . . . . . . . . . . . 23		4.1.5. createOffer . . . . . . . . . . . . . . . . . . . . . 23
	4.1.6. createAnswer . . . . . . . . . . . . . . . . . . . . 24		4.1.6. createAnswer . . . . . . . . . . . . . . . . . . . . 24
	4.1.7. SessionDescriptionType . . . . . . . . . . . . . . . 24		4.1.7. SessionDescriptionType . . . . . . . . . . . . . . . 25
	4.1.7.1. Use of Provisional Answers . . . . . . . . . . . 25		4.1.7.1. Use of Provisional Answers . . . . . . . . . . . 25
	4.1.7.2. Rollback . . . . . . . . . . . . . . . . . . . . 26		4.1.7.2. Rollback . . . . . . . . . . . . . . . . . . . . 26
	4.1.8. setLocalDescription . . . . . . . . . . . . . . . . . 27		4.1.8. setLocalDescription . . . . . . . . . . . . . . . . . 27
	4.1.9. setRemoteDescription . . . . . . . . . . . . . . . . 28		4.1.9. setRemoteDescription . . . . . . . . . . . . . . . . 28
	4.1.10. currentLocalDescription . . . . . . . . . . . . . . . 28		4.1.10. currentLocalDescription . . . . . . . . . . . . . . . 28
	4.1.11. pendingLocalDescription . . . . . . . . . . . . . . . 28		4.1.11. pendingLocalDescription . . . . . . . . . . . . . . . 28
	4.1.12. currentRemoteDescription . . . . . . . . . . . . . . 28		4.1.12. currentRemoteDescription . . . . . . . . . . . . . . 28
	4.1.13. pendingRemoteDescription . . . . . . . . . . . . . . 29		4.1.13. pendingRemoteDescription . . . . . . . . . . . . . . 29
	4.1.14. canTrickleIceCandidates . . . . . . . . . . . . . . . 29		4.1.14. canTrickleIceCandidates . . . . . . . . . . . . . . . 29
	4.1.15. setConfiguration . . . . . . . . . . . . . . . . . . 29		4.1.15. setConfiguration . . . . . . . . . . . . . . . . . . 30
	4.1.16. addIceCandidate . . . . . . . . . . . . . . . . . . . 30		4.1.16. addIceCandidate . . . . . . . . . . . . . . . . . . . 30
	5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 31		4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 31
	5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 31		4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 31
	5.1.1. Implementation Requirements . . . . . . . . . . . . . 31		4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 31
	5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 33		4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 31
	5.1.3. Profile Names and Interoperability . . . . . . . . . 33		4.2.4. setCodecPreferences . . . . . . . . . . . . . . . . . 32
	5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 34		5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 32
	5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 34		5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 32
	5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 40		5.1.1. Implementation Requirements . . . . . . . . . . . . . 33
	5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 43		5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 34
	5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 43		5.1.3. Profile Names and Interoperability . . . . . . . . . 34
	5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 44		5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 35
	5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 44		5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 35
	5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 44		5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 41
	5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 49		5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 44
	5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 50		5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 44
	5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 50		5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 45
	5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 50		5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 45
	5.5. Processing a Local Description . . . . . . . . . . . . . 51		5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 45
	5.6. Processing a Remote Description . . . . . . . . . . . . . 51		5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 50
	5.7. Parsing a Session Description . . . . . . . . . . . . . . 52		5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 51
	5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 53		5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 51
			5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 51
			5.5. Processing a Local Description . . . . . . . . . . . . . 52
			5.6. Processing a Remote Description . . . . . . . . . . . . . 53
			5.7. Parsing a Session Description . . . . . . . . . . . . . . 53
			5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 54
	5.7.2. Media Section Parsing . . . . . . . . . . . . . . . . 55		5.7.2. Media Section Parsing . . . . . . . . . . . . . . . . 55
	5.7.3. Semantics Verification . . . . . . . . . . . . . . . 57		5.7.3. Semantics Verification . . . . . . . . . . . . . . . 58
	5.8. Applying a Local Description . . . . . . . . . . . . . . 58		5.8. Applying a Local Description . . . . . . . . . . . . . . 59
	5.9. Applying a Remote Description . . . . . . . . . . . . . . 60		5.9. Applying a Remote Description . . . . . . . . . . . . . . 60
	5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 63		5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 64
	6. Demux placeholder . . . . . . . . . . . . . . . . . . . . . . 64		6. Processing RTP/RTCP packets . . . . . . . . . . . . . . . . . 66
	7. Processing RTP packets . . . . . . . . . . . . . . . . . . . 64		7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 68
	8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 66		7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 68
	8.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 66		7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 72
	8.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 70		8. Security Considerations . . . . . . . . . . . . . . . . . . . 81
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 80		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 82
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 81		11.1. Normative References . . . . . . . . . . . . . . . . . . 82
	12.1. Normative References . . . . . . . . . . . . . . . . . . 81		11.2. Informative References . . . . . . . . . . . . . . . . . 85
	12.2. Informative References . . . . . . . . . . . . . . . . . 84		Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 86
	Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 85		Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 87
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
	1. Introduction		1. Introduction
	This document describes how the W3C WEBRTC RTCPeerConnection		This document describes how the W3C WEBRTC RTCPeerConnection
	interface [W3C.WD-webrtc-20140617] is used to control the setup,		interface [W3C.WD-webrtc-20140617] is used to control the setup,
	management and teardown of a multimedia session.		management and teardown of a multimedia session.
	1.1. General Design of JSEP		1.1. General Design of JSEP
	The thinking behind WebRTC call setup has been to fully specify and		The thinking behind WebRTC call setup has been to fully specify and
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	m= section, and once a session description is applied, a m= section		m= section, and once a session description is applied, a m= section
	is always associated with exactly one RtpTransceiver.		is always associated with exactly one RtpTransceiver.
	RtpTransceivers can be created explicitly by the application or		RtpTransceivers can be created explicitly by the application or
	implicitly by calling setRemoteDescription with an offer that adds		implicitly by calling setRemoteDescription with an offer that adds
	new m= sections.		new m= sections.
	3.4.2. RtpSenders		3.4.2. RtpSenders
	RtpSenders allow the application to control how RTP media is sent.		RtpSenders allow the application to control how RTP media is sent.
	In particular, the application can control whether an RtpSender is
	active or not, which affects the directionality attribute of the
	associated m= section.
	3.4.3. RtpReceivers		3.4.3. RtpReceivers
	RtpReceivers allows the application to control how RTP media is		RtpReceivers allows the application to control how RTP media is
	received. In particular, the application can control whether an		received.
	RtpReceiver is active or not, which affects the directionality
	attribute of the associated m= section.
	3.5. ICE		3.5. ICE
	3.5.1. ICE Gathering Overview		3.5.1. ICE Gathering Overview
	JSEP gathers ICE candidates as needed by the application. Collection		JSEP gathers ICE candidates as needed by the application. Collection
	of ICE candidates is referred to as a gathering phase, and this is		of ICE candidates is referred to as a gathering phase, and this is
	triggered either by the addition of a new or recycled m= line to the		triggered either by the addition of a new or recycled m= line to the
	local session description, or new ICE credentials in the description,		local session description, or new ICE credentials in the description,
	indicating an ICE restart. Use of new ICE credentials can be		indicating an ICE restart. Use of new ICE credentials can be
	skipping to change at page 15, line 5 ¶		skipping to change at page 14, line 47 ¶
	3.6. Video Size Negotiation		3.6. Video Size Negotiation
	Video size negotiation is the process through which a receiver can		Video size negotiation is the process through which a receiver can
	use the "a=imageattr" SDP attribute [RFC6236] to indicate what video		use the "a=imageattr" SDP attribute [RFC6236] to indicate what video
	frame sizes it is capable of receiving. A receiver may have hard		frame sizes it is capable of receiving. A receiver may have hard
	limits on what its video decoder can process, or it may wish to		limits on what its video decoder can process, or it may wish to
	constrain what it receives due to application preferences, e.g. a		constrain what it receives due to application preferences, e.g. a
	specific size for the window in which the video will be displayed.		specific size for the window in which the video will be displayed.
			Note that certain codecs support transmission of samples with aspect
			ratios other than 1.0 (i.e., non-square pixels). JSEP
			implementations will not transmit non-square pixels, but SHOULD
			receive and render such video with the correct aspect ratio.
			However, sample aspect ratio has no impact on the size negotiation
			described below; all dimensions assume square pixels.
	3.6.1. Creating an imageattr Attribute		3.6.1. Creating an imageattr Attribute
	In order to determine the limits on what video resolution a receiver		In order to determine the limits on what video resolution a receiver
	wants to receive, it will intersect its decoder hard limits with any		wants to receive, it will intersect its decoder hard limits with any
	mandatory constraints that have been applied to the associated		mandatory constraints that have been applied to the associated
	MediaStreamTrack. If the decoder limits are unknown, e.g. when using		MediaStreamTrack. If the decoder limits are unknown, e.g. when using
	a software decoder, the mandatory constraints are used directly. For		a software decoder, the mandatory constraints are used directly. For
	the answerer, these mandatory constraints can be applied to the		the answerer, these mandatory constraints can be applied to the
	remote MediaStreamTracks that are created by a setRemoteDescription		remote MediaStreamTracks that are created by a setRemoteDescription
	call, and will affect the output of the ensuing createAnswer call.		call, and will affect the output of the ensuing createAnswer call.
	skipping to change at page 16, line 24 ¶		skipping to change at page 16, line 24 ¶
	of a given MediaStreamTrack, which is producing video of a certain		of a given MediaStreamTrack, which is producing video of a certain
	resolution, receives an "a=imageattr recv" attribute, it MUST check		resolution, receives an "a=imageattr recv" attribute, it MUST check
	to see if the original resolution meets the size criteria specified		to see if the original resolution meets the size criteria specified
	in the attribute, and adapt the resolution accordingly by scaling (if		in the attribute, and adapt the resolution accordingly by scaling (if
	appropriate). Note that when considering a MediaStreamTrack that is		appropriate). Note that when considering a MediaStreamTrack that is
	producing rotated video, the unrotated resolution MUST be used. This		producing rotated video, the unrotated resolution MUST be used. This
	is required regardless of whether the receiver supports performing		is required regardless of whether the receiver supports performing
	receive-side rotation (e.g., through CVO), as it significantly		receive-side rotation (e.g., through CVO), as it significantly
	simplifies the matching logic.		simplifies the matching logic.
	For an "a=imageattr recv" attribute, only size limits are considered.		For the purposes of resolution negotiation, only size limits are
	Any other values, e.g. aspect ratio, MUST be ignored.		considered. Any other values, e.g. picture or sample aspect ratio,
			MUST be ignored.
	When communicating with a non-JSEP endpoint, multiple relevant		When communicating with a non-JSEP endpoint, multiple relevant
	"a=imageattr recv" attributes may be received. If this occurs,		"a=imageattr recv" attributes may be received. If this occurs,
	attributes other than the one with the highest "q=" value MUST be		attributes other than the one with the highest "q=" value MUST be
	ignored.		ignored.
	If an "a=imageattr recv" attribute references a different video codec		If an "a=imageattr recv" attribute references a different video codec
	than what has been selected for the MediaStreamTrack, it MUST be		than what has been selected for the MediaStreamTrack, it MUST be
	ignored.		ignored.
	skipping to change at page 17, line 9 ¶		skipping to change at page 17, line 11 ¶
	upscaling policy for each sent track. For this case, if upscaling is		upscaling policy for each sent track. For this case, if upscaling is
	permitted by policy, the sender SHOULD apply upscaling in order to		permitted by policy, the sender SHOULD apply upscaling in order to
	provide the desired resolution. Otherwise, the sender MUST NOT apply		provide the desired resolution. Otherwise, the sender MUST NOT apply
	upscaling. The sender SHOULD NOT upscale in other cases, even if the		upscaling. The sender SHOULD NOT upscale in other cases, even if the
	policy permits it. Upscaling MUST NOT change the track aspect ratio.		policy permits it. Upscaling MUST NOT change the track aspect ratio.
	If there is no appropriate and permitted scaling mechanism that		If there is no appropriate and permitted scaling mechanism that
	allows the received size limits to be satisfied, the sender MUST NOT		allows the received size limits to be satisfied, the sender MUST NOT
	transmit the track.		transmit the track.
			If the attribute includes a "sar=" (sample aspect ratio) value set to
			something other than "1.0", indicating the receiver wants to receive
			non-square pixels, this cannot be satisfied and the sender MUST NOT
			transmit the track.
	In the special case of receiving a maximum resolution of [0, 0], as		In the special case of receiving a maximum resolution of [0, 0], as
	described above, the sender MUST NOT transmit the track.		described above, the sender MUST NOT transmit the track.
	3.7. Simulcast		3.7. Simulcast
	JSEP supports simulcast of a MediaStreamTrack, where multiple		JSEP supports simulcast of a MediaStreamTrack, where multiple
	encodings of the source media can be transmitted within the context		encodings of the source media can be transmitted within the context
	of a single m= section. The current JSEP API is designed to allow		of a single m= section. The current JSEP API is designed to allow
	applications to send simulcasted media but only to receive a single		applications to send simulcasted media but only to receive a single
	encoding. This allows for multi-user scenarios where each sending		encoding. This allows for multi-user scenarios where each sending
	skipping to change at page 20, line 12 ¶		skipping to change at page 20, line 18 ¶
	application wants to only keep a single session, it can simply		application wants to only keep a single session, it can simply
	terminate the sessions that it no longer needs.		terminate the sessions that it no longer needs.
	4. Interface		4. Interface
	This section details the basic operations that must be present to		This section details the basic operations that must be present to
	implement JSEP functionality. The actual API exposed in the W3C API		implement JSEP functionality. The actual API exposed in the W3C API
	may have somewhat different syntax, but should map easily to these		may have somewhat different syntax, but should map easily to these
	concepts.		concepts.
	4.1. Methods		4.1. PeerConnection
	4.1.1. Constructor		4.1.1. Constructor
	The PeerConnection constructor allows the application to specify		The PeerConnection constructor allows the application to specify
	global parameters for the media session, such as the STUN/TURN		global parameters for the media session, such as the STUN/TURN
	servers and credentials to use when gathering candidates, as well as		servers and credentials to use when gathering candidates, as well as
	the initial ICE candidate policy and pool size, and also the bundle		the initial ICE candidate policy and pool size, and also the bundle
	policy to use.		policy to use.
	If an ICE candidate policy is specified, it functions as described in		If an ICE candidate policy is specified, it functions as described in
	skipping to change at page 22, line 23 ¶		skipping to change at page 22, line 30 ¶
	The default multiplexing policy MUST be set to "require".		The default multiplexing policy MUST be set to "require".
	Implementations MAY choose to reject attempts by the application to		Implementations MAY choose to reject attempts by the application to
	set the multiplexing policy to "negotiate".		set the multiplexing policy to "negotiate".
	4.1.2. addTrack		4.1.2. addTrack
	The addTrack method adds a MediaStreamTrack to the PeerConnection,		The addTrack method adds a MediaStreamTrack to the PeerConnection,
	using the MediaStream argument to associate the track with other		using the MediaStream argument to associate the track with other
	tracks in the same MediaStream, so that they can be added to the same		tracks in the same MediaStream, so that they can be added to the same
	"LS" group when creating an offer or answer. addTrack attempts to		"LS" group when creating an offer or answer. addTrack attempts to
	minimize the number of transceivers as follows: The track will be		minimize the number of transceivers as follows: If the PeerConnection
	attached to the first compatible transceiver (of the same media type)		is in the "have-remote-offer" state, the track will be attached to
	which has never had a direction of "sendonly" or "sendrecv". If no		the first compatible transceiver that was created by the most recent
	such transceiver exists, then one will be constructed as described in		call to setRemoteDescription() and does not have a local track.
			Otherwise, a new transceiver will be created, as described in
	Section 4.1.3.		Section 4.1.3.
	4.1.3. addTransceiver		4.1.3. addTransceiver
	The addTransceiver method adds a new RTPTransceiver to the		The addTransceiver method adds a new RTPTransceiver to the
	PeerConnection. If a MediaStreamTrack argument is provided, then the		PeerConnection. If a MediaStreamTrack argument is provided, then the
	transceiver will be configured with that media type and the track		transceiver will be configured with that media type and the track
	will be attached to the transceiver. Otherwise, the application MUST		will be attached to the transceiver. Otherwise, the application MUST
	explicitly specify the type; this mode is useful for creating		explicitly specify the type; this mode is useful for creating
	recvonly transceivers as well as for creating transceivers to which a		recvonly transceivers as well as for creating transceivers to which a
	skipping to change at page 24, line 29 ¶		skipping to change at page 24, line 36 ¶
	codec/RTP/RTCP options negotiated for this session, and any		codec/RTP/RTCP options negotiated for this session, and any
	candidates that have been gathered by the ICE Agent. An options		candidates that have been gathered by the ICE Agent. An options
	parameter may be supplied to provide additional control over the		parameter may be supplied to provide additional control over the
	generated answer.		generated answer.
	As an answer, the generated SDP will contain a specific configuration		As an answer, the generated SDP will contain a specific configuration
	that specifies how the media plane should be established; for each		that specifies how the media plane should be established; for each
	SDP line, the generation of the SDP must follow the process defined		SDP line, the generation of the SDP must follow the process defined
	for generating an answer from the document that specifies the given		for generating an answer from the document that specifies the given
	SDP line. The exact handling of answer generation is detailed in		SDP line. The exact handling of answer generation is detailed in
	Section 5.3. below.		Section 5.3. below.
	Session descriptions generated by createAnswer must be immediately		Session descriptions generated by createAnswer must be immediately
	usable by setLocalDescription; like createOffer, the returned		usable by setLocalDescription; like createOffer, the returned
	description should reflect the current state of the system. Because		description should reflect the current state of the system. Because
	this method may need to inspect the system state to determine the		this method may need to inspect the system state to determine the
	currently available resources, it may need to be implemented as an		currently available resources, it may need to be implemented as an
	async operation.		async operation.
	Calling this method may do things such as generate new ICE		Calling this method may do things such as generate new ICE
	credentials, but does not trigger candidate gathering or change media		credentials, but does not trigger candidate gathering or change media
	skipping to change at page 27, line 31 ¶		skipping to change at page 27, line 41 ¶
	type field indicates whether the description should be processed as		type field indicates whether the description should be processed as
	an offer, provisional answer, or final answer; offers and answers are		an offer, provisional answer, or final answer; offers and answers are
	checked differently, using the various rules that exist for each SDP		checked differently, using the various rules that exist for each SDP
	line.		line.
	This API changes the local media state; among other things, it sets		This API changes the local media state; among other things, it sets
	up local resources for receiving and decoding media. In order to		up local resources for receiving and decoding media. In order to
	successfully handle scenarios where the application wants to offer to		successfully handle scenarios where the application wants to offer to
	change from one media format to a different, incompatible format, the		change from one media format to a different, incompatible format, the
	PeerConnection must be able to simultaneously support use of both the		PeerConnection must be able to simultaneously support use of both the
	current and pending local descriptions (e.g. support codecs that		current and pending local descriptions (e.g. support codecs that
	exist in both descriptions) until a final answer is received, at		exist in both descriptions) until a final answer is received, at
	which point the PeerConnection can fully adopt the pending local		which point the PeerConnection can fully adopt the pending local
	description, or roll back to the current description if the remote		description, or roll back to the current description if the remote
	side denied the change.		side denied the change.
	This API indirectly controls the candidate gathering process. When a		This API indirectly controls the candidate gathering process. When a
	local description is supplied, and the number of transports currently		local description is supplied, and the number of transports currently
	in use does not match the number of transports needed by the local		in use does not match the number of transports needed by the local
	description, the PeerConnection will create transports as needed and		description, the PeerConnection will create transports as needed and
	begin gathering candidates for them.		begin gathering candidates for them.
	skipping to change at page 31, line 19 ¶		skipping to change at page 31, line 25 ¶
	If the ufrag is not present, then the end-of-candidates indication		If the ufrag is not present, then the end-of-candidates indication
	MUST be assumed to apply to the relevant m= section in the most		MUST be assumed to apply to the relevant m= section in the most
	recently applied remote description. If neither the MID nor the m=		recently applied remote description. If neither the MID nor the m=
	index is present, then the indication MUST be assumed to apply to all		index is present, then the indication MUST be assumed to apply to all
	m= sections in the most recently applied remote description.		m= sections in the most recently applied remote description.
	This call will result in a change to the state of the ICE Agent, and		This call will result in a change to the state of the ICE Agent, and
	may result in a change to media state if it results in connectivity		may result in a change to media state if it results in connectivity
	being established.		being established.
			4.2. RtpTransceiver
			4.2.1. stop
			The stop method stops an RtpTransceiver. This will cause future
			calls to createOffer to generate a zero port for the associated m=
			section. See below for more details.
			4.2.2. stopped
			The stopped method returns "true" if the transceiver has been
			stopped, either by a call to stopTransceiver or by applying an answer
			that rejects the associated m= section, and "false" otherwise.
			A stopped RtpTransceiver does not send any outgoing RTP or RTCP or
			process any incoming RTP or RTCP. It cannot be restarted.
			4.2.3. setDirection
			The setDirection method sets the direction of a transceiver, which
			affects the direction attribute of the associated m= section on
			future calls to createOffer and createAnswer.
			When creating offers, the transceiver direction is directly reflected
			in the output, even for reoffers. When creating answers, the
			transceiver direction is intersected with the offered direction, as
			explained in the Section 5.3 section below.
			4.2.4. setCodecPreferences
			The setCodecPreferences method sets the codec preferences of a
			transceiver, which in turn affect the presence and order of codecs of
			the associated m= section on future calls to createOffer and
			createAnswer. Note that setCodecPreferences does not directly affect
			which codec the implemtation decides to send. It only affects which
			codecs the implementation indicates that it prefers to receive, via
			the offer or answer. Even when a codec is excluded by
			setCodecPreferences, it still may be used to send until the next
			offer/answer exchange discards it.
			The codec preferences of an RtpTransceiver can cause codecs to be
			excluded by subsequent calls to createOffer and createAnswer, in
			which case the corresponding media formats in the associated m=
			section will be excluded. The codec preferences cannot add media
			formats that would otherwise not be present. This includes codecs
			that were not negotiated in a previous offer/answer exchange that
			included the transceiver.
			The codec preferences of an RtpTransceiver can also determine the
			order of codecs in subsequent calls to createOffer and createAnswer,
			in which case the order of the media formats in the associated m=
			section will match. However, the codec preferences cannot change the
			order of the media formats after an answer containing the transceiver
			has been applied. At this point, codecs can only be removed, not
			reordered.
	5. SDP Interaction Procedures		5. SDP Interaction Procedures
	This section describes the specific procedures to be followed when		This section describes the specific procedures to be followed when
	creating and parsing SDP objects.		creating and parsing SDP objects.
	5.1. Requirements Overview		5.1. Requirements Overview
	JSEP implementations must comply with the specifications listed below		JSEP implementations must comply with the specifications listed below
	that govern the creation and processing of offers and answers.		that govern the creation and processing of offers and answers.
	skipping to change at page 34, line 7 ¶		skipping to change at page 35, line 23 ¶
	o Any profile matching the following patterns MUST be accepted:		o Any profile matching the following patterns MUST be accepted:
	"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]"		"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]"
	o Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no		o Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no
	effect; support for DTLS-SRTP is determined by the presence of one		effect; support for DTLS-SRTP is determined by the presence of one
	or more "a=fingerprint" attribute. Note that lack of an		or more "a=fingerprint" attribute. Note that lack of an
	"a=fingerprint" attribute will lead to negotiation failure.		"a=fingerprint" attribute will lead to negotiation failure.
	o The use of AVPF or AVP simply controls the timing rules used for		o The use of AVPF or AVP simply controls the timing rules used for
	RTCP feedback. If AVPF is provided, or an "a=rtcp-fb" attribute		RTCP feedback. If AVPF is provided, or an "a=rtcp-fb" attribute
	is present, assume AVPF timing, i.e. a default value of "trr-		is present, assume AVPF timing, i.e., a default value of "trr-
	int=0". Otherwise, assume that AVPF is being used in an AVP		int=0". Otherwise, assume that AVPF is being used in an AVP
	compatible mode and use AVP timing, i.e., "trr-int=4".		compatible mode and use AVP timing, i.e., "trr-int=4".
	o For data m= sections, JSEP endpoints MUST support receiving the		o For data m= sections, JSEP endpoints MUST support receiving the
	"UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards		"UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards
	compatibility) profiles.		compatibility) profiles.
	Note that re-offers by JSEP endpoints MUST use the correct profile		Note that re-offers by JSEP endpoints MUST use the correct profile
	strings even if the initial offer/answer exchange used an (incorrect)		strings even if the initial offer/answer exchange used an (incorrect)
	older profile string.		older profile string.
	skipping to change at page 36, line 11 ¶		skipping to change at page 37, line 27 ¶
	this m= section, but given that no candidates have yet been		this m= section, but given that no candidates have yet been
	gathered, the "dummy" port value of 9 (Discard) MUST be used, as		gathered, the "dummy" port value of 9 (Discard) MUST be used, as
	indicated in [I-D.ietf-ice-trickle], Section 5.1.		indicated in [I-D.ietf-ice-trickle], Section 5.1.
	o To properly indicate use of DTLS, the <proto> field MUST be set to		o To properly indicate use of DTLS, the <proto> field MUST be set to
	"UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8, if the		"UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8, if the
	default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as		default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as
	specified in [I-D.nandakumar-mmusic-proto-iana-registration] if		specified in [I-D.nandakumar-mmusic-proto-iana-registration] if
	the default candidate uses TCP transport.		the default candidate uses TCP transport.
			o If codec preferences have been set for the associated transceiver,
			media formats MUST be generated in the corresponding order, and
			MUST exclude any codecs not present in the codec preferences.
			o Unless excluded by the above restrictions, the media formats MUST
			include the mandatory audio/video codecs as specified in
			[I-D.ietf-rtcweb-audio](see Section 3) and
			[I-D.ietf-rtcweb-video](see Section 5).
	The m= line MUST be followed immediately by a "c=" line, as specified		The m= line MUST be followed immediately by a "c=" line, as specified
	in [RFC4566], Section 5.7. Again, as no candidates have yet been		in [RFC4566], Section 5.7. Again, as no candidates have yet been
	gathered, the "c=" line must contain the "dummy" value "IN IP4		gathered, the "c=" line must contain the "dummy" value "IN IP4
	0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1.		0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1.
	Each m= section MUST include the following attribute lines:		[I-D.ietf-mmusic-sdp-mux-attributes] groups SDP attributes into
			different categories. To avoid unnecessary duplication when
			bundling, Section 8.1 of [I-D.ietf-mmusic-sdp-bundle-negotiation]
			specifies that attributes of category IDENTICAL or TRANSPORT should
			not be repeated in bundled m= sections.
			The following attributes, which are of a category other than
			IDENTICAL or TRANSPORT, MUST be included in each m= section:
	o An "a=mid" line, as specified in [RFC5888], Section 4. When		o An "a=mid" line, as specified in [RFC5888], Section 4. When
	generating mid values, it is RECOMMENDED that the values be 3		generating mid values, it is RECOMMENDED that the values be 3
	bytes or less, to allow them to efficiently fit into the RTP		bytes or less, to allow them to efficiently fit into the RTP
	header extension defined in		header extension defined in
	[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11.		[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11.
	o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,
	containing the dummy value "9 IN IP4 0.0.0.0", because no
	candidates have yet been gathered.
	o A direction attribute which is the same as that of the associated		o A direction attribute which is the same as that of the associated
	transceiver.		transceiver.
	o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as		o For each media format on the m= line, "a=rtpmap" and "a=fmtp"
	specified in [RFC4566], Section 6. The audio and video codecs		lines, as specified in [RFC4566], Section 6, and [RFC3264],
	that MUST be supported are specified in		Section 5.1.
	[I-D.ietf-rtcweb-audio](see Section 3) and
	[I-D.ietf-rtcweb-video](see Section 5).
	o If this m= section is for media with configurable frame sizes,		o If this m= section is for media with configurable frame sizes,
	e.g. audio, an "a=maxptime" line, indicating the smallest of the		e.g. audio, an "a=maxptime" line, indicating the smallest of the
	maximum supported frame sizes out of all codecs included above, as		maximum supported frame sizes out of all codecs included above, as
	specified in [RFC4566], Section 6.		specified in [RFC4566], Section 6.
	o If this m= section is for video media, and there are known		o If this m= section is for video media, and there are known
	limitations on the size of images which can be decoded, an		limitations on the size of images which can be decoded, an
	"a=imageattr" line, as specified in Section 3.6.		"a=imageattr" line, as specified in Section 3.6.
	skipping to change at page 37, line 11 ¶		skipping to change at page 38, line 36 ¶
	of the primary codec and an "a=fmtp" line that references the		of the primary codec and an "a=fmtp" line that references the
	payload type of the primary codec, as specified in [RFC4588],		payload type of the primary codec, as specified in [RFC4588],
	Section 8.1.		Section 8.1.
	o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,		o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,
	as specified in [RFC4566], Section 6. The FEC mechanisms that		as specified in [RFC4566], Section 6. The FEC mechanisms that
	MUST be supported are specified in [I-D.ietf-rtcweb-fec],		MUST be supported are specified in [I-D.ietf-rtcweb-fec],
	Section 6, and specific usage for each media type is outlined in		Section 6, and specific usage for each media type is outlined in
	Sections 4 and 5.		Sections 4 and 5.
	o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245],
	Section 15.4.
	o One or more "a=fingerprint" line(s) for each of the endpoint's
	certificates, as specified in [I-D.ietf-mmusic-4572-update].
	o An "a=setup" line, as specified in [RFC4145], Section 4, and
	clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
	The role value in the offer MUST be "actpass".
	o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1.
	o An "a=rtcp-mux-only" line, as specified in
	[I-D.ietf-mmusic-mux-exclusive] Section 4, if and only if the RTP/
	RTCP multiplexing policy is "require".
	o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5.
	o For each supported RTP header extension, an "a=extmap" line, as		o For each supported RTP header extension, an "a=extmap" line, as
	specified in [RFC5285], Section 5. The list of header extensions		specified in [RFC5285], Section 5. The list of header extensions
	that SHOULD/MUST be supported is specified in		that SHOULD/MUST be supported is specified in
	[I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions		[I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions
	that require encryption MUST be specified as indicated in		that require encryption MUST be specified as indicated in
	[RFC6904], Section 4.		[RFC6904], Section 4.
	o For each supported RTCP feedback mechanism, an "a=rtcp-fb"		o For each supported RTCP feedback mechanism, an "a=rtcp-fb"
	mechanism, as specified in [RFC4585], Section 4.2. The list of		mechanism, as specified in [RFC4585], Section 4.2. The list of
	RTCP feedback mechanisms that SHOULD/MUST be supported is		RTCP feedback mechanisms that SHOULD/MUST be supported is
	specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1.		specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1.
	o An "a=ssrc" line, as specified in [RFC5576], Section 4.1,
	indicating the SSRC to be used for sending media, along with the
	mandatory "cname" source attribute, as specified in Section 6.1,
	indicating the CNAME for the source. The CNAME MUST be generated
	in accordance with Section 4.9 of [I-D.ietf-rtcweb-rtp-usage].
	o If RTX is supported for this media type, another "a=ssrc" line
	with the RTX SSRC, and an "a=ssrc-group" line, as specified in
	[RFC5576], section 4.2, with semantics set to "FID" and including
	the primary and RTX SSRCs.
	o If FEC is supported for this media type, another "a=ssrc" line
	with the FEC SSRC, and an "a=ssrc-group" line with semantics set
	to "FEC-FR" and including the primary and FEC SSRCs, as specified
	in [RFC5956], section 4.3. For simplicity, if both RTX and FEC
	are supported, the FEC SSRC MUST be the same as the RTX SSRC.
	o If the bundle policy for this PeerConnection is set to "max-		o If the bundle policy for this PeerConnection is set to "max-
	bundle", and this is not the first m= section, or the bundle		bundle", and this is not the first m= section, or the bundle
	policy is set to "balanced", and this is not the first m= section		policy is set to "balanced", and this is not the first m= section
	for this media type, an "a=bundle-only" line.		for this media type, an "a=bundle-only" line.
	o If the RtpSender of the RtpTransceiver associated with this		o If the RtpTransceiver has a sendrecv or sendonly direction:
	m=section is active:
	* An "a=msid" line, as specified in [I-D.ietf-mmusic-msid],		* An "a=msid" line, as specified in [I-D.ietf-mmusic-msid],
	Section 2.		Section 2.
	* An "a=ssrc" line, as specified in [RFC5576], Section 4.1,		o If the RtpTransceiver has a sendrecv or sendonly direction, and
	indicating the SSRC to be used for sending media, along with		the application has specified RID values or has specified more
	the mandatory "cname" source attribute, as specified in		than one encoding in the RtpSenders's parameters, an "a=rid" line
	Section 6.1, indicating the CNAME for the source. The CNAME		for each encoding specified. The "a=rid" line is specified in
	MUST be generated in accordance with Section 4.9 of
	[I-D.ietf-rtcweb-rtp-usage].
	* If RTX is supported for this media type, another "a=ssrc" line
	with the RTX SSRC, and an "a=ssrc-group" line, as specified in
	[RFC5576], section 4.2, with semantics set to "FID" and
	including the primary and RTX SSRCs.
	* If FEC is supported for this media type, another "a=ssrc" line
	with the FEC SSRC, and an "a=ssrc-group" line with semantics
	set to "FEC-FR" and including the primary and FEC SSRCs, as
	specified in [RFC5956], section 4.3. For simplicity, if both
	RTX and FEC are supported, the FEC SSRC MUST be the same as the
	RTX SSRC.
	o If the RtpTransceiver's RtpSender is active, and the application
	has specified RID values or has specified more than one encoding
	in the RtpSenders's parameters, an "a=rid" line for each encoding
	specified. The "a=rid" line is specified in
	[I-D.ietf-mmusic-rid], and its direction MUST be "send". If the		[I-D.ietf-mmusic-rid], and its direction MUST be "send". If the
	application has chosen a RID value, it MUST be used as the rid-		application has chosen a RID value, it MUST be used as the rid-
	identifier; otherwise a RID value MUST be generated by the		identifier; otherwise a RID value MUST be generated by the
	implementation. When generating RID values, it is RECOMMENDED		implementation. When generating RID values, it is RECOMMENDED
	that the values be 3 bytes or less, to allow them to efficiently		that the values be 3 bytes or less, to allow them to efficiently
	fit into the RTP header extension defined in		fit into the RTP header extension defined in
	[I-D.ietf-avtext-rid], Section 11. If no encodings have been		[I-D.ietf-avtext-rid], Section 11. If no encodings have been
	specified, or only one encoding is specified but without a RID		specified, or only one encoding is specified but without a RID
	value, then no "a=rid" lines are generated.		value, then no "a=rid" lines are generated.
	o If the RtpTransceiver's RtpSender is active and more than one		o If the RtpTransceiver has a sendrecv or sendonly direction and
	"a=rid" line has been generated, an "a=simulcast" line, with		more than one "a=rid" line has been generated, an "a=simulcast"
	direction "send", as defined in [I-D.ietf-mmusic-sdp-simulcast],		line, with direction "send", as defined in
	Section 6.2. The list of RIDs MUST include all of the RID		[I-D.ietf-mmusic-sdp-simulcast], Section 6.2. The list of RIDs
	identifiers used in the "a=rid" lines for this m= section.		MUST include all of the RID identifiers used in the "a=rid" lines
			for this m= section.
			The following attributes, which are of category IDENTICAL or
			TRANSPORT, MUST appear only in "m=" sections which either have a
			unique address or which are associated with the bundle-tag. (In
			initial offers, this means those "m=" sections which do not contain
			an "a=bundle-only" attribute.
			o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245],
			Section 15.4.
			o An "a=fingerprint" line for each of the endpoint's certificates,
			as specified in [RFC4572], Section 5; the digest algorithm used
			for the fingerprint MUST match that used in the certificate
			signature.
			o An "a=setup" line, as specified in [RFC4145], Section 4, and
			clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
			The role value in the offer MUST be "actpass".
			o An "a=dtls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp]
			Section 5.2.
			o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,
			containing the dummy value "9 IN IP4 0.0.0.0", because no
			candidates have yet been gathered.
			o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1.
			o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5.
	Lastly, if a data channel has been created, a m= section MUST be		Lastly, if a data channel has been created, a m= section MUST be
	generated for data. The <media> field MUST be set to "application"		generated for data. The <media> field MUST be set to "application"
	and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default		and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default
	candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default		candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default
	candidate uses TCP transport [I-D.ietf-mmusic-sctp-sdp]. The "fmt"		candidate uses TCP transport [I-D.ietf-mmusic-sctp-sdp]. The "fmt"
	value MUST be set to "webrtc-datachannel" as specified in		value MUST be set to "webrtc-datachannel" as specified in
	[I-D.ietf-mmusic-sctp-sdp], Section 4.1.		[I-D.ietf-mmusic-sctp-sdp], Section 4.1.
	Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",		Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
	"a=fingerprint", and "a=setup" lines MUST be included as mentioned		"a=fingerprint", "a=dtls-id", and "a=setup" lines MUST be included as
	above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-		mentioned above, along with an "a=fmtp:webrtc-datachannel" line and
	port" line referencing the SCTP port number as defined in		an "a=sctp-port" line referencing the SCTP port number as defined in
	[I-D.ietf-mmusic-sctp-sdp], Section 4.1.		[I-D.ietf-mmusic-sctp-sdp], Section 4.1.
	Once all m= sections have been generated, a session-level "a=group"		Once all m= sections have been generated, a session-level "a=group"
	attribute MUST be added as specified in [RFC5888]. This attribute		attribute MUST be added as specified in [RFC5888]. This attribute
	MUST have semantics "bundle", and MUST include the mid identifiers of		MUST have semantics "bundle", and MUST include the mid identifiers of
	each m= section. The effect of this is that the browser offers all		each m= section. The effect of this is that the browser offers all
	m= sections as one bundle group. However, whether the m= sections		m= sections as one bundle group. However, whether the m= sections
	are bundle-only or not depends on the bundle policy.		are bundle-only or not depends on the bundle policy.
	The next step is to generate session-level lip sync groups as defined		The next step is to generate session-level lip sync groups as defined
	skipping to change at page 40, line 4 ¶		skipping to change at page 40, line 51 ¶
	media level SHOULD generally be at the media level even if they are		media level SHOULD generally be at the media level even if they are
	identical. This promotes readability, especially if one of a set of		identical. This promotes readability, especially if one of a set of
	initially identical attributes is subsequently changed.		initially identical attributes is subsequently changed.
	Attributes other than the ones specified above MAY be included,		Attributes other than the ones specified above MAY be included,
	except for the following attributes which are specifically		except for the following attributes which are specifically
	incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage],		incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage],
	and MUST NOT be included:		and MUST NOT be included:
	o "a=crypto"		o "a=crypto"
	o "a=key-mgmt"
			o "a=key-mgmt"
	o "a=ice-lite"		o "a=ice-lite"
	Note that when bundle is used, any additional attributes that are		Note that when bundle is used, any additional attributes that are
	added MUST follow the advice in [I-D.ietf-mmusic-sdp-mux-attributes]		added MUST follow the advice in [I-D.ietf-mmusic-sdp-mux-attributes]
	on how those attributes interact with bundle.		on how those attributes interact with bundle.
	Note that these requirements are in some cases stricter than those of		Note that these requirements are in some cases stricter than those of
	SDP. Implementations MUST be prepared to accept compliant SDP even		SDP. Implementations MUST be prepared to accept compliant SDP even
	if it would not conform to the requirements for generating SDP in		if it would not conform to the requirements for generating SDP in
	this specification.		this specification.
	skipping to change at page 41, line 25 ¶		skipping to change at page 42, line 23 ¶
	o If an RtpTransceiver is stopped and is not associated with an m=		o If an RtpTransceiver is stopped and is not associated with an m=
	section, an m= section MUST NOT be generated for it. This		section, an m= section MUST NOT be generated for it. This
	prevents adding back RtpTransceivers whose m= sections were		prevents adding back RtpTransceivers whose m= sections were
	recycled and used for a new RtpTransceiver in a previous offer/		recycled and used for a new RtpTransceiver in a previous offer/
	answer exchange, as described above.		answer exchange, as described above.
	o If an RtpTransceiver has been stopped and is associated with an m=		o If an RtpTransceiver has been stopped and is associated with an m=
	section, and the m= section is not being recycled as described		section, and the m= section is not being recycled as described
	above, an m= section MUST be generated for it with the port set to		above, an m= section MUST be generated for it with the port set to
	zero and the "a=msid", "a=ssrc", and "a=ssrc-group" lines removed.		zero and the "a=msid" line removed.
	o For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc",		o For RtpTransceivers that are not stopped, the "a=msid" line MUST
	and "a=ssrc-group" lines MUST stay the same if they are present in		stay the same if they are present in the current description.
	the current description.
	o Each "m=" and c=" line MUST be filled in with the port, protocol,		o Each "m=" and c=" line MUST be filled in with the port, protocol,
	and address of the default candidate for the m= section, as		and address of the default candidate for the m= section, as
	described in [RFC5245], Section 4.3. If ICE checking has already		described in [RFC5245], Section 4.3. If ICE checking has already
	completed for one or more candidate pairs and a candidate pair is		completed for one or more candidate pairs and a candidate pair is
	in active use, then that pair MUST be used, even if ICE has not		in active use, then that pair MUST be used, even if ICE has not
	yet completed. Note that this differs from the guidance in		yet completed. Note that this differs from the guidance in
	[RFC5245], Section 9.1.2.2, which only refers to offers created		[RFC5245], Section 9.1.2.2, which only refers to offers created
	when ICE has completed. Each "a=rtcp" attribute line MUST also be		when ICE has completed. In each case, if no RTP candidates have
	filled in with the port and address of the appropriate default		yet been gathered, dummy values MUST be used, as described above.
	candidate, either the default RTP or RTCP candidate, depending on
	whether RTCP multiplexing is currently active or not. Note that
	if RTCP multiplexing is being offered, but not yet active, the
	default RTCP candidate MUST be used, as indicated in [RFC5761],
	section 5.1.3. In each case, if no candidates of the desired type
	have yet been gathered, dummy values MUST be used, as described
	above.
	o Each "a=mid" line MUST stay the same.		o Each "a=mid" line MUST stay the same.
	o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless		o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
	the ICE configuration has changed (either changes to the supported		the ICE configuration has changed (either changes to the supported
	STUN/TURN servers, or the ICE candidate policy), or the		STUN/TURN servers, or the ICE candidate policy), or the
	"IceRestart" option ( Section 5.2.3.1 was specified. If the m=		"IceRestart" option ( Section 5.2.3.1 was specified. If the m=
	section is bundled into another m= section, it still MUST NOT		section is bundled into another m= section, it still MUST NOT
	contain any ICE credentials.		contain any ICE credentials.
			o If the m= section is not bundled into another m= section, an
			"a=rtcp" attribute line MUST be added with of the default RTCP
			candidate, as indicated in [RFC5761], section 5.1.3.
	o If the m= section is not bundled into another m= section, for each		o If the m= section is not bundled into another m= section, for each
	candidate that has been gathered during the most recent gathering		candidate that has been gathered during the most recent gathering
	phase (see Section 3.5.1), an "a=candidate" line MUST be added, as		phase (see Section 3.5.1), an "a=candidate" line MUST be added, as
	defined in [RFC5245], Section 4.3., paragraph 3. If candidate		defined in [RFC5245], Section 4.3., paragraph 3. If candidate
	gathering for the section has completed, an "a=end-of-candidates"		gathering for the section has completed, an "a=end-of-candidates"
	attribute MUST be added, as described in [I-D.ietf-ice-trickle],		attribute MUST be added, as described in [I-D.ietf-ice-trickle],
	Section 9.3. If the m= section is bundled into another m=		Section 9.3. If the m= section is bundled into another m=
	section, both "a=candidate" and "a=end-of-candidates" MUST be		section, both "a=candidate" and "a=end-of-candidates" MUST be
	omitted.		omitted.
	o For RtpTransceivers that are still present, the "a=msid",		o For RtpTransceivers that are still present, the "a=msid" line MUST
	"a=ssrc", and "a=ssrc-group" lines MUST stay the same.		stay the same.
	o For RtpTransceivers that are still present, the "a=rid" lines MUST		o For RtpTransceivers that are still present, the "a=rid" lines MUST
	stay the same.		stay the same.
	o For RtpTransceivers that are still present, any "a=simulcast" line		o For RtpTransceivers that are still present, any "a=simulcast" line
	MUST stay the same.		MUST stay the same.
	o If any RtpTransceiver has been stopped, the port MUST be set to		o If any RtpTransceiver has been stopped, the port MUST be set to
	zero and the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST be		zero and the "a=msid" line MUST be removed.
	removed.
	o If any RtpTransceiver has been added, and there exists a m=		o If any RtpTransceiver has been added, and there exists a m=
	section with a zero port in the current local description or the		section with a zero port in the current local description or the
	current remote description, that m= section MUST be recycled by		current remote description, that m= section MUST be recycled by
	generating a m= section for the added RtpTransceiver as if the m=		generating a m= section for the added RtpTransceiver as if the m=
	section were being added to session description, except that		section were being added to session description, except that
	instead of adding it, the generated m= section replaces the m=		instead of adding it, the generated m= section replaces the m=
	section with a zero port.		section with a zero port.
	If the initial offer was applied using setLocalDescription, and an		If the initial offer was applied using setLocalDescription, and an
	skipping to change at page 43, line 6 ¶		skipping to change at page 43, line 44 ¶
	setRemoteDescription, meaning the PeerConnection is in the "remote-		setRemoteDescription, meaning the PeerConnection is in the "remote-
	pranswer" or "stable" states, an offer is generated based on the		pranswer" or "stable" states, an offer is generated based on the
	negotiated session descriptions by following the steps mentioned for		negotiated session descriptions by following the steps mentioned for
	the "local-offer" state above.		the "local-offer" state above.
	In addition, for each non-recycled, non-rejected m= section in the		In addition, for each non-recycled, non-rejected m= section in the
	new offer, the following adjustments are made based on the contents		new offer, the following adjustments are made based on the contents
	of the corresponding m= section in the current remote description:		of the corresponding m= section in the current remote description:
	o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST		o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
	only include codecs present in the most recent answer.		only include codecs present in the most recent answer which have
			not been excluded by the codec preferences of the associated
			transceiver.
			o The media formats on the m= line MUST be generated in the same
			order as in the current local description.
	o The RTP header extensions MUST only include those that are present		o The RTP header extensions MUST only include those that are present
	in the most recent answer.		in the most recent answer.
	o The RTCP feedback extensions MUST only include those that are		o The RTCP feedback extensions MUST only include those that are
	present in the most recent answer.		present in the most recent answer.
			o The "a=rtcp" line MUST only be added if the most recent answer did
			not include an "a=rtcp-mux" line.
	o The "a=rtcp-mux" line MUST only be added if present in the most		o The "a=rtcp-mux" line MUST only be added if present in the most
	recent answer.		recent answer.
	o The "a=rtcp-mux-only" line MUST only be added if present in the		o The "a=rtcp-mux-only" line MUST only be added if present in the
	most recent answer.		most recent answer.
	o The "a=rtcp-rsize" line MUST only be added if present in the most		o The "a=rtcp-rsize" line MUST only be added if present in the most
	recent answer.		recent answer.
	The "a=group:BUNDLE" attribute MUST include the mid identifiers		The "a=group:BUNDLE" attribute MUST include the mid identifiers
	skipping to change at page 46, line 27 ¶		skipping to change at page 47, line 27 ¶
	following rules must be followed:		following rules must be followed:
	o The port value would normally be set to the port of the default		o The port value would normally be set to the port of the default
	ICE candidate for this m= section, but given that no candidates		ICE candidate for this m= section, but given that no candidates
	have yet been gathered, the "dummy" port value of 9 (Discard) MUST		have yet been gathered, the "dummy" port value of 9 (Discard) MUST
	be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1.		be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1.
	o The <proto> field MUST be set to exactly match the <proto> field		o The <proto> field MUST be set to exactly match the <proto> field
	for the corresponding m= line in the offer.		for the corresponding m= line in the offer.
			o If codec preferences have been set for the associated transceiver,
			media formats MUST be generated in the corresponding order, and
			MUST exclude any codecs not present in the codec preferences or
			not present in the offer.
			o Unless excluded by the above restrictions, the media formats MUST
			include the mandatory audio/video codecs as specified in
			[I-D.ietf-rtcweb-audio](see Section 3) and
			[I-D.ietf-rtcweb-video](see Section 5).
	The m= line MUST be followed immediately by a "c=" line, as specified		The m= line MUST be followed immediately by a "c=" line, as specified
	in [RFC4566], Section 5.7. Again, as no candidates have yet been		in [RFC4566], Section 5.7. Again, as no candidates have yet been
	gathered, the "c=" line must contain the "dummy" value "IN IP4		gathered, the "c=" line must contain the "dummy" value "IN IP4
	0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1.		0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1.
	If the offer supports bundle, all m= sections to be bundled must use		If the offer supports bundle, all m= sections to be bundled must use
	the same ICE credentials and candidates; all m= sections not being		the same ICE credentials and candidates; all m= sections not being
	bundled must use unique ICE credentials and candidates. Each m=		bundled must use unique ICE credentials and candidates. Each m=
	section MUST include the following:		section MUST contain the following attributes (which are of attribute
			types other than IDENTICAL and TRANSPORT):
	o If and only if present in the offer, an "a=mid" line, as specified		o If and only if present in the offer, an "a=mid" line, as specified
	in [RFC5888], Section 9.1. The "mid" value MUST match that		in [RFC5888], Section 9.1. The "mid" value MUST match that
	specified in the offer.		specified in the offer.
	o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,		o A direction attribute, determined by applying the rules regarding
	containing the dummy value "9 IN IP4 0.0.0.0", because no		the offered direction specified in [RFC3264], Section 6.1, and
	candidates have yet been gathered.		then intersecting with the direction of the associated
			RtpTransceiver. For example, in the case where an m= section is
	o A direction attribute which is the same as that of the associated		offered as "sendonly", and the local transceiver is set to
	transceiver.		"sendrecv", the result in the answer is a "recvonly" direction.
	o For each supported codec that is present in the offer, "a=rtpmap"		o For each media format on the m= line, "a=rtpmap" and "a=fmtp"
	and "a=fmtp" lines, as specified in [RFC4566], Section 6, and		lines, as specified in [RFC4566], Section 6, and [RFC3264],
	[RFC3264], Section 6.1. The audio and video codecs that MUST be		Section 6.1.
	supported are specified in [I-D.ietf-rtcweb-audio](see Section 3)
	and [I-D.ietf-rtcweb-video](see Section 5).
	o If this m= section is for media with configurable frame sizes,		o If this m= section is for media with configurable frame sizes,
	e.g. audio, an "a=maxptime" line, indicating the smallest of the		e.g. audio, an "a=maxptime" line, indicating the smallest of the
	maximum supported frame sizes out of all codecs included above, as		maximum supported frame sizes out of all codecs included above, as
	specified in [RFC4566], Section 6.		specified in [RFC4566], Section 6.
	o If this m= section is for video media, and there are known		o If this m= section is for video media, and there are known
	limitations on the size of images which can be decoded, an		limitations on the size of images which can be decoded, an
	"a=imageattr" line, as specified in Section 3.6.		"a=imageattr" line, as specified in Section 3.6.
	skipping to change at page 47, line 26 ¶		skipping to change at page 48, line 37 ¶
	indicating "rtx" with the clock rate of the primary codec and an		indicating "rtx" with the clock rate of the primary codec and an
	"a=fmtp" line that references the payload type of the primary		"a=fmtp" line that references the payload type of the primary
	codec, as specified in [RFC4588], Section 8.1.		codec, as specified in [RFC4588], Section 8.1.
	o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,		o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,
	as specified in [RFC4566], Section 6. The FEC mechanisms that		as specified in [RFC4566], Section 6. The FEC mechanisms that
	MUST be supported are specified in [I-D.ietf-rtcweb-fec],		MUST be supported are specified in [I-D.ietf-rtcweb-fec],
	Section 6, and specific usage for each media type is outlined in		Section 6, and specific usage for each media type is outlined in
	Sections 4 and 5.		Sections 4 and 5.
	o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245],
	Section 15.4.
	o One or more "a=fingerprint" line(s) for each of the endpoint's
	certificates, as specified in [I-D.ietf-mmusic-4572-update].
	o An "a=setup" line, as specified in [RFC4145], Section 4, and
	clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
	The role value in the answer MUST be "active" or "passive"; the
	"active" role is RECOMMENDED.
	o If present in the offer, an "a=rtcp-mux" line, as specified in
	[RFC5761], Section 5.1.1. If the "require" RTCP multiplexing
	policy is set and no "a=rtcp-mux" line is present in the offer,
	then the m=line MUST be marked as rejected by setting the port in
	the m= line to zero, as indicated in [RFC3264], Section 6.
	o If present in the offer, an "a=rtcp-mux-only" line, as specified
	in [I-D.ietf-mmusic-mux-exclusive], Section 4.3.
	o If present in the offer, an "a=rtcp-rsize" line, as specified in
	[RFC5506], Section 5.
	o For each supported RTP header extension that is present in the		o For each supported RTP header extension that is present in the
	offer, an "a=extmap" line, as specified in [RFC5285], Section 5.		offer, an "a=extmap" line, as specified in [RFC5285], Section 5.
	The list of header extensions that SHOULD/MUST be supported is		The list of header extensions that SHOULD/MUST be supported is
	specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header		specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header
	extensions that require encryption MUST be specified as indicated		extensions that require encryption MUST be specified as indicated
	in [RFC6904], Section 4.		in [RFC6904], Section 4.
	o For each supported RTCP feedback mechanism that is present in the		o For each supported RTCP feedback mechanism that is present in the
	offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585],		offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585],
	Section 4.2. The list of RTCP feedback mechanisms that SHOULD/		Section 4.2. The list of RTCP feedback mechanisms that SHOULD/
	MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage],		MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage],
	Section 5.1.		Section 5.1.
	o If the RtpSender of the RtpTransceiver associated with this		o If the RtpTransceiver has a sendrecv or sendonly direction:
	m=section is active:
	* An "a=msid" line, as specified in [I-D.ietf-mmusic-msid],		* An "a=msid" line, as specified in [I-D.ietf-mmusic-msid],
	Section 2.		Section 2.
	* An "a=ssrc" line, as specified in [RFC5576], Section 4.1,		Each m= section which is not bundled into another m= section, MUST
	indicating the SSRC to be used for sending media, along with		contain the following attributes (which are of category IDENTICAL or
	the mandatory "cname" source attribute, as specified in		TRANSPORT):
	Section 6.1, indicating the CNAME for the source. The CNAME
	MUST be generated in accordance with Section 4.9 of
	[I-D.ietf-rtcweb-rtp-usage].
	* If RTX has been negotiated for this m= section, another		o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245],
	"a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as		Section 15.4.
	specified in [RFC5576], section 4.2, with semantics set to
	"FID" and including the primary and RTX SSRCs.
	* If FEC has been negotiated for this m= section, another		o An "a=fingerprint" line for each of the endpoint's certificates,
	"a=ssrc" line with the FEC SSRC, and an "a=ssrc-group" line		as specified in [RFC4572], Section 5; the digest algorithm used
	with semantics set to "FEC-FR" and including the primary and		for the fingerprint MUST match that used in the certificate
	FEC SSRCs, as specified in [RFC5956], section 4.3. For		signature.
	simplicity, if both RTX and FEC are supported, the FEC SSRC
	MUST be the same as the RTX SSRC.		o An "a=setup" line, as specified in [RFC4145], Section 4, and
			clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
			The role value in the answer MUST be "active" or "passive"; the
			"active" role is RECOMMENDED. The role value MUST be consistent
			with the existing DTLS connection, if one exists and is being
			continued.
			o An "a=dtls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp]
			Section 5.3.
			o If present in the offer, an "a=rtcp-mux" line, as specified in
			[RFC5761], Section 5.1.1. Otherwise, an "a=rtcp" line, as
			specified in [RFC3605], Section 2.1, containing the dummy value "9
			IN IP4 0.0.0.0" (because no candidates have yet been gathered).
			o If present in the offer, an "a=rtcp-rsize" line, as specified in
			[RFC5506], Section 5.
	If a data channel m= section has been offered, a m= section MUST also		If a data channel m= section has been offered, a m= section MUST also
	be generated for data. The <media> field MUST be set to		be generated for data. The <media> field MUST be set to
	"application" and the <proto> and "fmt" fields MUST be set to exactly		"application" and the <proto> and "fmt" fields MUST be set to exactly
	match the fields in the offer.		match the fields in the offer.
	Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",		Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
	"a=candidate", "a=fingerprint", and "a=setup" lines MUST be included		"a=candidate", "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST
	as mentioned above, along with an "a=fmtp:webrtc-datachannel" line		be included under the conditions described above, along with an
	and an "a=sctp-port" line referencing the SCTP port number as defined		"a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line
	in [I-D.ietf-mmusic-sctp-sdp], Section 4.1.		referencing the SCTP port number as defined in
			[I-D.ietf-mmusic-sctp-sdp], Section 4.1.
	If "a=group" attributes with semantics of "BUNDLE" are offered,		If "a=group" attributes with semantics of "BUNDLE" are offered,
	corresponding session-level "a=group" attributes MUST be added as		corresponding session-level "a=group" attributes MUST be added as
	specified in [RFC5888]. These attributes MUST have semantics		specified in [RFC5888]. These attributes MUST have semantics
	"BUNDLE", and MUST include the all mid identifiers from the offered		"BUNDLE", and MUST include the all mid identifiers from the offered
	bundle groups that have not been rejected. Note that regardless of		bundle groups that have not been rejected. Note that regardless of
	the presence of "a=bundle-only" in the offer, no m= sections in the		the presence of "a=bundle-only" in the offer, no m= sections in the
	answer should have an "a=bundle-only" line.		answer should have an "a=bundle-only" line.
	Attributes that are common between all m= sections MAY be moved to		Attributes that are common between all m= sections MAY be moved to
	skipping to change at page 49, line 42 ¶		skipping to change at page 50, line 42 ¶
	setLocalDescription, an answer is generated by following the steps in		setLocalDescription, an answer is generated by following the steps in
	the "have-remote-offer" state above, along with these exceptions:		the "have-remote-offer" state above, along with these exceptions:
	o The "s=" and "t=" lines MUST stay the same.		o The "s=" and "t=" lines MUST stay the same.
	o Each "m=" and c=" line MUST be filled in with the port and address		o Each "m=" and c=" line MUST be filled in with the port and address
	of the default candidate for the m= section, as described in		of the default candidate for the m= section, as described in
	[RFC5245], Section 4.3. Note, however, that the m= line protocol		[RFC5245], Section 4.3. Note, however, that the m= line protocol
	need not match the default candidate, because this protocol value		need not match the default candidate, because this protocol value
	must instead match what was supplied in the offer, as described		must instead match what was supplied in the offer, as described
	above. Each "a=rtcp" attribute line MUST also be filled in with
	the port and address of the appropriate default candidate, either
	the default RTP or RTCP candidate, depending on whether RTCP
	multiplexing is enabled in the answer. In each case, if no
	candidates of the desired type have yet been gathered, dummy
	values MUST be used, as described in the initial answer section
	above.		above.
			o The media formats on the m= line MUST be generated in the same
			order as in the current local description.
	o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless		o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
	the m= section is restarting, in which case new ICE credentials		the m= section is restarting, in which case new ICE credentials
	must be created as specified in [RFC5245], Section 9.2.1.1. If		must be created as specified in [RFC5245], Section 9.2.1.1. If
	the m= section is bundled into another m= section, it still MUST		the m= section is bundled into another m= section, it still MUST
	NOT contain any ICE credentials.		NOT contain any ICE credentials.
			o If the m= section is not bundled into another m= section and RTCP
			multiplexing is not active, an "a=rtcp" attribute line MUST be
			filled in with the port and address of the default RTCP candidate.
			If no RTCP candidates have yet been gathered, dummy values MUST be
			used, as described in the initial answer section above.
	o If the m= section is not bundled into another m= section, for each		o If the m= section is not bundled into another m= section, for each
	candidate that has been gathered during the most recent gathering		candidate that has been gathered during the most recent gathering
	phase (see Section 3.5.1), an "a=candidate" line MUST be added, as		phase (see Section 3.5.1), an "a=candidate" line MUST be added, as
	defined in [RFC5245], Section 4.3., paragraph 3. If candidate		defined in [RFC5245], Section 4.3., paragraph 3. If candidate
	gathering for the section has completed, an "a=end-of-candidates"		gathering for the section has completed, an "a=end-of-candidates"
	attribute MUST be added, as described in [I-D.ietf-ice-trickle],		attribute MUST be added, as described in [I-D.ietf-ice-trickle],
	Section 9.3. If the m= section is bundled into another m=		Section 9.3. If the m= section is bundled into another m=
	section, both "a=candidate" and "a=end-of-candidates" MUST be		section, both "a=candidate" and "a=end-of-candidates" MUST be
	omitted.		omitted.
	o For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc",		o For RtpTransceivers that are not stopped, the "a=msid" line MUST
	and "a=ssrc-group" lines MUST stay the same.		stay the same.
	5.3.3. Options Handling		5.3.3. Options Handling
	The createAnswer method takes as a parameter an RTCAnswerOptions		The createAnswer method takes as a parameter an RTCAnswerOptions
	object. The set of parameters for RTCAnswerOptions is different than		object. The set of parameters for RTCAnswerOptions is different than
	those supported in RTCOfferOptions; the IceRestart option is		those supported in RTCOfferOptions; the IceRestart option is
	unnecessary, as ICE credentials will automatically be changed for all		unnecessary, as ICE credentials will automatically be changed for all
	m= lines where the offerer chose to perform ICE restart.		m= lines where the offerer chose to perform ICE restart.
	The following options are supported in RTCAnswerOptions.		The following options are supported in RTCAnswerOptions.
	skipping to change at page 52, line 38 ¶		skipping to change at page 53, line 43 ¶
	it is invalid. The exact details of this process are explained		it is invalid. The exact details of this process are explained
	below.		below.
	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 its defining ABNF, check that it conforms to [RFC4566] and		according to its defining ABNF, check that it conforms to [RFC4566]
	[RFC3264] semantics, and then either parse and store or discard the		and [RFC3264] semantics, and then either parse and store or discard
	provided value, as described below. A partial list of ABNF		the provided value, as described below.
	definitions for SDP attributes can found in:
	+-------------------------+----------------------------------+
	| Attribute | Reference |
	+-------------------------+----------------------------------+
	| ptime | [RFC4566] Section 9 |
	| maxptime | [RFC4566] Section 9 |
	| rtpmap | [RFC4566] Section 9 |
	| recvonly | [RFC4566] Section 9 |
	| sendrecv | [RFC4566] Section 9 |
	| sendonly | [RFC4566] Section 9 |
	| inactive | [RFC4566] Section 9 |
	| framerate | [RFC4566] Section 9 |
	| fmtp | [RFC4566] Section 9 |
	| quality | [RFC4566] Section 9 |
	| msid | [I-D.ietf-mmusic-msid] Section 2 |
	| rtcp | [RFC3605] Section 2.1 |
	| setup | [RFC4145] Section 3, 4, and 5 |
	| connection | [RFC4145] Section 3, 4, and 5 |
	| fingerprint | [RFC4572] Section 5 |
	| rtcp-fb | [RFC4585] Section 4.2 |
	| candidate | [RFC5245] Section 15 |
	| extmap | [RFC5285] Section 7 |
	| mid | [RFC5888] Section 4 and 5 |
	| group | [RFC5888] Section 4 and 5 |
	| imageattr | [RFC6236] Section 3.1 |
	| extmap (encrypt option) | [RFC6904] Section 4 |
	+-------------------------+----------------------------------+
	Table 1: SDP ABNF References
	[TODO: ensure that every line is listed below.]
	If the 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,
	This ensures that implementations do not accidentally misinterpret		even if the value is to be discarded. This ensures that
	ambiguous SDP.		implementations do not accidentally misinterpret ambiguous SDP.
	5.7.1. Session-Level Parsing		5.7.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, and their ordering		same type (typically "a=") can occur in any order, and their ordering
	is not meaningful.		is not meaningful.
	For non-attribute (non-"a=") lines, their sequencing, syntax, and		The following non-attribute lines are not meaningful in the JSEP
	semantics, are checked, as mentioned above. The following lines are		context and MAY be discarded once they have been checked.
	not meaningful in the JSEP context and MAY be discarded once they
	have been checked.
	The "c=" line MUST be checked for syntax but its value is not		The "c=" line MUST be checked for syntax but its value is not
	used. This supersedes the guidance in [RFC5245], Section 6.1, to		used. This supersedes the guidance in [RFC5245], Section 6.1, to
	use "ice-mismatch" to indicate mismatches between "c=" and the		use "ice-mismatch" to indicate mismatches between "c=" and the
	candidate lines; because JSEP always uses ICE, "ice-mismatch" is		candidate lines; because JSEP always uses ICE, "ice-mismatch" is
	not useful in this context.		not useful in this context.
	The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines are		The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines are
	not used by this specification; they MUST be checked for syntax		not used by this specification; they MUST be checked for syntax
	but their values are not used.		but their values are not used.
	The remaining lines are processed as follows:		The remaining non-attribute lines are processed as follows:
	The "v=" line MUST have a version of 0, as specified in [RFC4566],		The "v=" line MUST have a version of 0, as specified in [RFC4566],
	Section 5.1.		Section 5.1.
	The "o=" line MUST be parsed as specified in [RFC4566],		The "o=" line MUST be parsed as specified in [RFC4566],
	Section 5.2.		Section 5.2.
	The "b=" line, if present, MUST be parsed as specified in		The "b=" line, if present, MUST be parsed as specified in
	[RFC4566], Section 5.8, and the bwtype and bandwidth values		[RFC4566], Section 5.8, and the bwtype and bandwidth values
	stored.		stored.
	Specific processing MUST be applied for the following session-level		Finally, the attribute lines are processed. Specific processing MUST
	attribute ("a=") lines:		be applied for the following session-level attribute ("a=") lines:
	o Any "a=group" lines are parsed as specified in [RFC5888],		o Any "a=group" lines are parsed as specified in [RFC5888],
	Section 5, and the group's semantics and mids are stored.		Section 5, and the group's semantics and mids are stored.
	o If present, a single "a=ice-lite" line is parsed as specified in		o If present, a single "a=ice-lite" line is parsed as specified in
	[RFC5245], Section 15.3, and a value indicating the presence of		[RFC5245], Section 15.3, and a value indicating the presence of
	ice-lite is stored.		ice-lite is stored.
	o If present, a single "a=ice-ufrag" line is parsed as specified in		o If present, a single "a=ice-ufrag" line is parsed as specified in
	[RFC5245], Section 15.4, and the ufrag value is stored.		[RFC5245], Section 15.4, and the ufrag value is stored.
	skipping to change at page 55, line 8 ¶		skipping to change at page 55, line 19 ¶
	in [RFC5245], Section 15.5, and the set of specified options is		in [RFC5245], Section 15.5, and the set of specified options is
	stored.		stored.
	o Any "a=fingerprint" lines are parsed as specified in [RFC4572],		o Any "a=fingerprint" lines are parsed as specified in [RFC4572],
	Section 5, and the set of fingerprint and algorithm values is		Section 5, and the set of fingerprint and algorithm values is
	stored.		stored.
	o If present, a single "a=setup" line is parsed as specified in		o If present, a single "a=setup" line is parsed as specified in
	[RFC4145], Section 4, and the setup value is stored.		[RFC4145], Section 4, and the setup value is stored.
			o If present, a single "a=dtls-id" line is parsed as specified in
			[I-D.ietf-mmusic-dtls-sdp] Section 5, and the dtls-id value is
			stored.
	o Any "a=extmap" lines are parsed as specified in [RFC5285],		o Any "a=extmap" lines are parsed as specified in [RFC5285],
	Section 5, and their values are stored.		Section 5, and their values are stored.
	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 media sections.		continues with the lines in media sections.
	5.7.2. Media Section Parsing		5.7.2. Media Section Parsing
	Like the session-level lines, the media session lines MUST occur in		Like the session-level lines, the media session 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],
	skipping to change at page 55, line 47 ¶		skipping to change at page 56, line 15 ¶
	o If present, a single "a=ice-ufrag" line is parsed as specified in		o If present, a single "a=ice-ufrag" line is parsed as specified in
	[RFC5245], Section 15.4, and the ufrag value is stored.		[RFC5245], Section 15.4, and the ufrag value is stored.
	o If present, a single "a=ice-pwd" line is parsed as specified in		o If present, a single "a=ice-pwd" line is parsed as specified in
	[RFC5245], Section 15.4, and the password value is stored.		[RFC5245], Section 15.4, and the password value is stored.
	o If present, a single "a=ice-options" line is parsed as specified		o If present, a single "a=ice-options" line is parsed as specified
	in [RFC5245], Section 15.5, and the set of specified options is		in [RFC5245], Section 15.5, and the set of specified options is
	stored.		stored.
			o Any "a=candidate" attributes MUST be parsed as specified in
			[RFC5245], Section 15.1, and their values stored.
			o Any "a=remote-candidates" attributes MUST be parsed as specified
			in [RFC5245], Section 15.2, but their values are ignored.
			o If present, a single "a=end-of-candidates" attribute MUST be
			parsed as specified in [I-D.ietf-ice-trickle], Section 8.2, and
			its presence or absence flagged and stored.
	o Any "a=fingerprint" lines are parsed as specified in [RFC4572],		o Any "a=fingerprint" lines are parsed as specified in [RFC4572],
	Section 5, and the set of fingerprint and algorithm values is		Section 5, and the set of fingerprint and algorithm values is
	stored.		stored.
	o If present, a single "a=setup" line is parsed as specified in
	[RFC4145], Section 4, and the setup value is stored.
	If the "m=" proto value indicates use of RTP, as described in the		If the "m=" proto value indicates use of RTP, as described in the
	Section 5.1.3 section above, the following attribute lines MUST be		Section 5.1.3 section above, the following attribute lines MUST be
	processed:		processed:
	o The "m=" fmt value MUST be parsed as specified in [RFC4566],		o The "m=" fmt value MUST be parsed as specified in [RFC4566],
	Section 5.14, and the individual values stored.		Section 5.14, and the individual values stored.
	o Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in		o Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in
	[RFC4566], Section 6, and their values stored.		[RFC4566], Section 6, and their values stored.
	o If present, a single "a=ptime" line MUST be parsed as described in		o If present, a single "a=ptime" line MUST be parsed as described in
	[RFC4566], Section 6, and its value stored.		[RFC4566], Section 6, and its value stored.
	o If present, a single "a=maxptime" line MUST be parsed as described		o If present, a single "a=maxptime" line MUST be parsed as described
	in [RFC4566], Section 6, and its value stored.		in [RFC4566], Section 6, and its value stored.
	o If present, a single direction attribute line (e.g. "a=sendrecv")		o If present, a single direction attribute line (e.g. "a=sendrecv")
	MUST be parsed as described in [RFC4566], Section 6, and its value		MUST be parsed as described in [RFC4566], Section 6, and its value
	stored.		stored.
	o Any "a=ssrc" or "a=ssrc-group" attributes MUST be parsed as		o Any "a=ssrc" or "a=ssrc-group" attributes MUST be parsed as
	specified in [RFC5576], Sections 4.1-4.2, and their values stored.		specified in [RFC5576], Sections 4.1-4.2, and their values stored.
	o Any "a=extmap" attributes MUST be parsed as specified in		o Any "a=extmap" attributes MUST be parsed as specified in
	[RFC5285], Section 5, and their values stored.		[RFC5285], Section 5, and their values stored.
	o Any "a=rtcp-fb" attributes MUST be parsed as specified in		o Any "a=rtcp-fb" attributes MUST be parsed as specified in
	skipping to change at page 57, line 5 ¶		skipping to change at page 57, line 31 ¶
	flagged and stored.		flagged and stored.
	o If present, a single "a=rtcp" attribute MUST be parsed as		o If present, a single "a=rtcp" attribute MUST be parsed as
	specified in [RFC3605], Section 2.1, but its value is ignored, as		specified in [RFC3605], Section 2.1, but its value is ignored, as
	this information is superfluous when using ICE.		this information is superfluous when using ICE.
	o If present, a single "a=msid" attribute MUST be parsed as		o If present, a single "a=msid" attribute MUST be parsed as
	specified in [I-D.ietf-mmusic-msid], Section 3.2, and its value		specified in [I-D.ietf-mmusic-msid], Section 3.2, and its value
	stored.		stored.
	o Any "a=candidate" attributes MUST be parsed as specified in
	[RFC5245], Section 4.3, and their values stored.
	o Any "a=remote-candidates" attributes MUST be parsed as specified
	in [RFC5245], Section 4.3, but their values are ignored.
	o If present, a single "a=end-of-candidates" attribute MUST be
	parsed as specified in [I-D.ietf-ice-trickle], Section 8.2, and
	its presence or absence flagged and stored.
	o Any "a=imageattr" attributes MUST be parsed as specified in		o Any "a=imageattr" attributes MUST be parsed as specified in
	[RFC6236], Section 3, and their values stored.		[RFC6236], Section 3, and their values stored.
	o Any "a=rid" lines MUST be parsed as specified in		o Any "a=rid" lines MUST be parsed as specified in
	[I-D.ietf-mmusic-rid], Section 10, and their values stored.		[I-D.ietf-mmusic-rid], Section 10, and their values stored.
	o If present, a single "a=simulcast" line MUST be parsed as		o If present, a single "a=simulcast" line MUST be parsed as
	specified in [I-D.ietf-mmusic-sdp-simulcast], and its values		specified in [I-D.ietf-mmusic-sdp-simulcast], and its values
	stored.		stored.
	skipping to change at page 58, line 8 ¶		skipping to change at page 58, line 24 ¶
	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.2 MUST be present. These		features enumerated in Section 5.1.2 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.
	* ICE ufrag and password values, which MUST comply with the size		* ICE ufrag and password values, which MUST comply with the size
	limits specified in [RFC5245], Section 15.4.		limits specified in [RFC5245], Section 15.4.
			* dtls-id value, which MUST be set according to
			[I-D.ietf-mmusic-dtls-sdp] Section 5. If this is a re-offer
			and the dtls-id value is different from that presently in use,
			the DTLS connection is not being continued and the remote
			description MUST be part of an ICE restart, together with new
			ufrag and password values. If this is an answer, the dtls-id
			value, if present, MUST be the same as in the offer.
	* DTLS setup value, which MUST be set according to the rules		* DTLS setup value, which MUST be set according to the rules
	specified in [RFC5763], Section 5, and MUST be consistent with		specified in [RFC5763], Section 5 and MUST be consistent with
	the selected role of the current DTLS connection, if one		the selected role of the current DTLS connection, if one exists
	exists.[TODO: may need revision, i.e., use of actpass		and is being continued.
	* DTLS fingerprint values, where at least one fingerprint MUST be		* DTLS fingerprint values, where at least one fingerprint MUST be
	present.		present.
	o All RID values referenced in an "a=simulcast" line MUST exist as		o All RID values referenced in an "a=simulcast" line MUST exist as
	"a=rid" lines.		"a=rid" lines.
	o Each m= section is also checked to ensure prohibited features are		o Each m= section is also checked to ensure prohibited features are
	not used. If this is a local description, the "ice-lite"		not used. If this is a local description, the "ice-lite"
	attribute MUST NOT be specified.		attribute MUST NOT be specified.
	skipping to change at page 61, line 32 ¶		skipping to change at page 62, line 8 ¶
	following steps:		following steps:
	+ If the m= section is sendrecv or recvonly, and there are		+ If the m= section is sendrecv or recvonly, and there are
	RtpTransceivers of the same type that were added to the		RtpTransceivers of the same type that were added to the
	PeerConnection by addTrack and are not associated with any		PeerConnection by addTrack and are not associated with any
	m= section and are not stopped, find the first (according to		m= section and are not stopped, find the first (according to
	the canonical order described in Section 5.2.1) such		the canonical order described in Section 5.2.1) such
	RtpTransceiver.		RtpTransceiver.
	+ If no RtpTransceiver was found in the previous step, create		+ If no RtpTransceiver was found in the previous step, create
	one with an inactive RtpSender and active RtpReceiver.		one with a recvonly direction.
	+ Associate the found or created RtpTransceiver with the m=		+ Associate the found or created RtpTransceiver with the m=
	section by setting the value of the RtpTransceiver's mid		section by setting the value of the RtpTransceiver's mid
	attribute to the MID of the m= section. If the m= section		attribute to the MID of the m= section. If the m= section
	does not include a MID (i.e., the remote side does not		does not include a MID (i.e., the remote side does not
	support the MID extension), generate a value for the		support the MID extension), generate a value for the
	RtpTransceiver mid attribute, following the guidance for		RtpTransceiver mid attribute, following the guidance for
	"a=mid" mentioned in Section 5.2.1.		"a=mid" mentioned in Section 5.2.1.
	* For each specified media format that is also supported by the		* For each specified media format that is also supported by the
	skipping to change at page 62, line 49 ¶		skipping to change at page 63, line 26 ¶
	5% to RTCP. If more accurate control of bandwidth is needed,		5% to RTCP. If more accurate control of bandwidth is needed,
	"TIAS" should be used instead of "AS".		"TIAS" should be used instead of "AS".
	* For any "RR" or "RS" bandwidth values, handle as specified in		* For any "RR" or "RS" bandwidth values, handle as specified in
	[RFC3556], Section 2.		[RFC3556], Section 2.
	* Any specified "CT" bandwidth value MUST be ignored, as the		* Any specified "CT" bandwidth value MUST be ignored, as the
	meaning of this construct at the media level is not well		meaning of this construct at the media level is not well
	defined.		defined.
	* [TODO: handling of CN, telephone-event, "red"]
	* If the media section is of type audio:		* If the media section is of type audio:
			+ For each specified "CN" media format, enable DTX for all
			supported media formats with the same clockrate, as
			described in [RFC3389], Section 5, except for formats that
			have their own internal DTX mechanisms. DTX for such
			formats (e.g., Opus) is controlled via fmtp parameters, as
			discussed in Section 5.2.3.2.
			+ For each specified "telephone-event" media format, enable
			DTMF transmission for all supported media formats with the
			same clockrate, as described in [RFC4733], Section 2.5.1.2.
			If the application attempts to transmit DTMF when using a
			media format that does not have a corresponding telephone-
			event format, this MUST result in an error.
	+ For any specified "ptime" value, configure the available		+ For any specified "ptime" value, configure the available
	media formats to use the specified packet size. If the		media formats to use the specified packet size. If the
	specified size is not supported for a media format, use the		specified size is not supported for a media format, use the
	next closest value instead.		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 the Section 5.10 section below.		follow the processing defined in the Section 5.10 section below.
	5.10. Applying an Answer		5.10. 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 media section, the following steps MUST be performed:		For each media section, the following steps MUST be performed:
	o If the media section has been rejected (i.e. port is set to zero		o If the media section has been rejected (i.e. port is set to zero
	in the answer), stop any reception or transmission of media for		in the answer), stop any reception or transmission of media for
	this section, and discard any associated ICE components, as		this section, and discard any associated ICE components, as
	described in Section 9.2.1.3 of [RFC5245].		described in Section 9.2.1.3 of [RFC5245].
	o If the remote DTLS fingerprint has been changed, tear down the		o If the remote DTLS fingerprint has been changed or the dtls-id has
	existing DTLS connection.		changed, tear down the DTLS connection. If a DTLS connection
			needs to be torn down but the answer does not indicate an ICE
			restart, an error MUST be generated. If an ICE restart is
			performed without a change in dtls-id or fingerprint, then the
			same DTLS connection is continued over the new ICE channel.
	o If no valid DTLS connection exists, prepare to start a DTLS		o If no valid DTLS connection exists, prepare to start a DTLS
	connection, using the specified roles and fingerprints, on any		connection, using the specified roles and fingerprints, on any
	underlying ICE components, once they are active.		underlying ICE components, once they are active.
	o If the media section proto value indicates use of RTP:		o If the media section proto value indicates use of RTP:
	* If the media section references any media formats, RTP header		* If the media section references any media formats, RTP header
	extensions, or RTCP feedback mechanisms that were not present		extensions, or RTCP feedback mechanisms that were not present
	in the corresponding media section in the offer, this indicates		in the corresponding media section in the offer, this indicates
	a negotiation problem and MUST result in an error.		a negotiation problem and MUST result in an error.
	* If the media section has RTCP mux enabled, discard any RTCP		* If the media section has RTCP mux enabled, discard any RTCP
	component, and begin or continue muxing RTCP over the RTP		component, and begin or continue muxing RTCP over the RTP
	component, as specified in [RFC5761], Section 5.1.3.		component, as specified in [RFC5761], Section 5.1.3.
	Otherwise, transmit RTCP over the RTCP component; if no RTCP		Otherwise, prepare to transmit RTCP over the RTCP component; if
	component exists, because RTCP mux was previously enabled, this		no RTCP component exists, because RTCP mux was previously
	MUST result in an error.		enabled, this MUST result in an error.
	* If the media section has reduced-size RTCP enabled, configure		* If the media section has reduced-size RTCP enabled, configure
	the RTCP transmission for this media section to use reduced-		the RTCP transmission for this media section to use reduced-
	size RTCP, as specified in [RFC5506].		size RTCP, as specified in [RFC5506].
	* [TODO: enable appropriate rtcp-fb mechanisms]
	* If the directional attribute in the answer is of type		* If the directional attribute in the answer is of type
	"sendrecv" or "sendonly", prepare to start transmitting media		"sendrecv" or "sendonly", choose the media format to send as
	using the most preferred media format from the remote		the most preferred media format from the remote description
	description that is also present in the answer, as described in		that is also present in the answer, as described in [RFC3264],
	[RFC3264], Sections 6.1 and 7, once the underlying transport		Sections 6.1 and 7, and start transmitting RTP media once the
	layers have been established. [TODO: add discusssion of		underlying transport layers have been established. If a SSRC
	RED/FEC/RTX/CN] The payload type mapping from the remote		has not already been chosen for this outgoing RTP stream,
	description is used to determine payload types for the outgoing		choose a random one.
	RTP streams. Any RTP header extensions that were negotiated
	should be included in the outgoing RTP streams, using the		* The payload type mapping from the remote description is used to
	extension mapping from the remote description; if the RID		determine payload types for the outgoing RTP streams, including
	header extension has been negotiated, and RID values are		the payload type for the send media format chosen above. Any
	specified, include the RID header extension in the outgoing RTP		RTP header extensions that were negotiated should be included
	streams, as indicated in [I-D.ietf-mmusic-rid], Section 4). If		in the outgoing RTP streams, using the extension mapping from
	simulcast is negotiated, send the number of Source RTP Streams		the remote description; if the RID header extension has been
	as specified in [I-D.ietf-mmusic-sdp-simulcast], Section 6.2.2.		negotiated, and RID values are specified, include the RID
			header extension in the outgoing RTP streams, as indicated in
			[I-D.ietf-mmusic-rid], Section 4.
			* If simulcast has been negotiated, send the number of Source RTP
			Streams as specified in [I-D.ietf-mmusic-sdp-simulcast],
			Section 6.2.2.
			* If the send media format chosen above has a corresponding "rtx"
			media format, or a FEC mechanism has been negotiated, establish
			a Redundancy RTP Stream with a random SSRC for each Source RTP
			Stream, and start or continue transmitting RTX/FEC packets as
			needed.
			* If the send media format chosen above has a corresponding "red"
			media format of the same clockrate, allow redundant encoding
			using the specified format for resiliency purposes, as
			discussed in [I-D.ietf-rtcweb-fec], Section 3.2. Note that
			unlike RTX or FEC media formats, the "red" format is
			transmitted on the Source RTP Stream, not the Redundancy RTP
			Stream.
			* Enable the RTCP feedback mechanisms referenced in the media
			section for all Source RTP Streams using the specified media
			formats. Specifically, begin or continue sending the requested
			feedback types and reacting to received feedback, as specified
			in [RFC4585], Section 4.2. When sending RTCP feedback, use the
			SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC;
			if no outgoing Source RTP Stream exists, choose a random one.
	* If the directional attribute is of type "recvonly" or		* If the directional attribute is of type "recvonly" or
	"inactive", stop transmitting RTP media, although RTCP should		"inactive", stop transmitting all RTP media, but continue
	still be sent, as described in [RFC3264], Section 5.1.		sending RTCP, as described in [RFC3264], Section 5.1.
	o If the media section proto value indicates use of SCTP:		o If the media section proto value indicates use of SCTP:
	* If no SCTP association yet exists, prepare to initiate a SCTP		* If no SCTP association yet exists, prepare to initiate a SCTP
	association over the associated ICE component and DTLS		association over the associated ICE component and DTLS
	connection, using the local SCTP port value from the local		connection, using the local SCTP port value from the local
	description, and the remote SCTP port value from the remote		description, and the remote SCTP port value from the remote
	description, as described in [I-D.ietf-mmusic-sctp-sdp],		description, as described in [I-D.ietf-mmusic-sctp-sdp],
	Section 10.2.		Section 10.2.
	If the answer contains valid bundle groups, discard any ICE		If the answer contains valid bundle groups, discard any ICE
	components for the m= sections that will be bundled onto the primary		components for the m= sections that will be bundled onto the primary
	ICE components in each bundle, and begin muxing these m= sections		ICE components in each bundle, and begin muxing these m= sections
	accordingly, as described in		accordingly, as described in
	[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2.		[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2.
	6. Demux placeholder		6. Processing RTP/RTCP packets
	RTP demux algo goes here
	7. Processing RTP packets
	Note: The following algorithm does not yet have WG consensus but is		Note: The following algorithm does not yet have WG consensus but is
	included here as something concrete for the working group to discuss.		included here as something concrete for the working group to discuss.
	When an RTP packet is received by a transport and passes SRTP		When an RTP packet is received by a transport and passes SRTP
	authentication, that packet needs to be routed to the correct		authentication, that packet needs to be routed to the correct
	RtpReceiver. For each transport, the following steps MUST be		RtpReceiver. For each transport, the following steps MUST be
	followed to prepare to route packets:		followed to prepare to route packets:
	Construct a table mapping MID to RtpReceiver for each RtpReceiver		Construct a table mapping MID to RtpReceiver for each RtpReceiver
	configured to receive from this transport.		configured to receive from this transport.
	Construct a table mapping SSRC to RtpReceiver for each RtpReceiver		Construct a table mapping incoming SSRC to RtpReceiver for each
	configured to receive from this transport and for each SSRC that		RtpReceiver configured to receive from this transport and for each
	RtpReceiver is configured to receive. Some of the SSRCs may be		SSRC that RtpReceiver is configured to receive. Some of the SSRCs
	presesnt in the m= section corresponding to that RtpReceiver in		may be present in the m= section corresponding to that RtpReceiver
	the remote description.		in the remote description.
			Construct a table mapping outgoing SSRC to RtpSender for each
			RtpSender configured to transmit from this transport and for each
			SSRC that RtpSender is configured to use when sending.
	Construct a table mapping payload type to RtpReceiver for each		Construct a table mapping payload type to RtpReceiver for each
	RtpReceiver configured to receive from this transport and for each		RtpReceiver configured to receive from this transport and for each
	payload type that RtpReceiver is configured to receive. The		payload type that RtpReceiver is configured to receive. The
	payload types of a given RtpReceiver are found in the m= section		payload types of a given RtpReceiver are found in the m= section
	corresponding to that RtpReceiver in the local description. If		corresponding to that RtpReceiver in the local description. If
	any payload type could map to more than one RtpReceiver, map to		any payload type could map to more than one RtpReceiver, map to
	the RtpReceiver whose m= section appears earliest in the local		the RtpReceiver whose m= section appears earliest in the local
	description.		description.
			As RtpTransceivers (and, thus, RtpReceivers) are added, removed,
			stopped, or reconfigured, the tables above must also be updated.
	For each RTP packet received, the following steps MUST be followed to		For each RTP packet received, the following steps MUST be followed to
	route the packet:		route the packet:
	If the packet has a MID and that MID is not in the table mapping		If the packet has a MID and that MID is not in the table mapping
	MID to RtpReceiver, drop the packet and stop.		MID to RtpReceiver, drop the packet and stop.
	If the packet has a MID and that MID is in the table mapping MID		If the packet has a MID and that MID is in the table mapping MID
	to RtpReceiver, update the SSRC mapping table to include an entry		to RtpReceiver, update the incoming SSRC mapping table to include
	mapping the packet's SSRC to the RtpReceiver.		an entry that maps the packet's SSRC to the RtpReceiver for that
			MID.
	If the packet's SSRC is in the SSRC mapping table, route the		If the packet's SSRC is in the incoming SSRC mapping table,
	packet to the mapped RtpReceiver and stop.		deliver the packet to the associated RtpReceiver and stop.
	If the packet's payload type is in the payload type table, update		If the packet's payload type is in the payload type table, update
	the the SSRC mapping table to include an entry mapping the		the the incoming SSRC mapping table to include an entry that maps
	packet's SSRC to the RtpReceiver. Deliver the packet to the		the packet's SSRC to the RtpReceiver for that payload type. In
	RtpReceiver and stop.		addition, deliver the packet to the associated RtpReceiver and
			stop.
	Otherwise, drop the packet.		Otherwise, drop the packet.
			For each RTCP packet received (including each RTCP packet that is
			part of a compound RTCP packet), the following type-specific handling
			MUST be performed to route the packet:
			If the packet is of type SR, and the sender SSRC for the packet is
			found in the incoming SSRC table, deliver a copy of the packet to
			the RtpReceiver associated with that SSRC. In addition, for each
			report block in the report whose SSRC is found in the outgoing
			SSRC table, deliver a copy of the RTCP packet to the RtpSender
			associated with that SSRC.
			If the packet is of type RR, for each report block in the packet
			whose SSRC is found in the outgoing SSRC table, deliver a copy of
			the RTCP packet to the RtpSender associated with that SSRC.
			If the packet is of type SDES, and the sender SSRC for the packet
			is found in the incoming SSRC table, deliver the packet to the
			RtpReceiver associated with that SSRC. In addition, for each
			chunk in the packet that contains a MID that is in the table
			mapping MID to RtpReceiver, update the incoming SSRC mapping table
			to include an entry that maps the SSRC for that chunk to the
			RtpReceiver associated with that MID. (This case can occur when
			RTCP for a source is received before any RTP packets.)
			If the packet is of type BYE, for each SSRC indicated in the
			packet that is found in the incoming SSRC table, deliver a copy of
			the packet to the RtpReceiver associated with that SSRC.
			If the packet is of type RTPFB or PSFB, as defined in [RFC4585],
			and the media source SSRC for the packet is found in the outgoing
			SSRC table, deliver the packet to the RtpSender associated with
			that SSRC.
	After packets are routed to the RtpReceiver, further processing of		After packets are routed to the RtpReceiver, further processing of
	the RTP packets is done at the RtpReceiver level. This includes		the RTP packets is done at the RtpReceiver level. This includes
	using [I-D.ietf-mmusic-rid] to determine which RTP streams depend on		using [I-D.ietf-mmusic-rid] to distinguish between multiple Encoded
	or repair other RTP streams.		Streams, as well as determine which Source RTP stream should be
			repaired by a given Redundancy RTP stream. If the RTP packet's PT
	As RtpTransceivers (and, thus, RtpReceivers) are added, removed,		does not match any codec in use by the RtpReceiver, the packet will
	stopped, or reconfigured, the tables above must also be updated.		be dropped.
	8. Examples		7. Examples
	Note that this example section shows several SDP fragments. To		Note that this example section shows several SDP fragments. To
	format in 72 columns, some of the lines in SDP have been split into		format in 72 columns, some of the lines in SDP have been split into
	multiple lines, where leading whitespace indicates that a line is a		multiple lines, where leading whitespace indicates that a line is a
	continuation of the previous line. In addition, some blank lines		continuation of the previous line. In addition, some blank lines
	have been added to improve readability but are not valid in SDP.		have been added to improve readability but are not valid in SDP.
	More examples of SDP for WebRTC call flows can be found in		More examples of SDP for WebRTC call flows can be found in
	[I-D.nandakumar-rtcweb-sdp].		[I-D.nandakumar-rtcweb-sdp].
	8.1. Simple Example		7.1. Simple Example
	This section shows a very simple example that sets up a minimal audio		This section shows a very simple example that sets up a minimal audio
	/ video call between two browsers and does not use trickle ICE. The		/ video call between two browsers and does not use trickle ICE. The
	example in the following section provides a more realistic example of		example in the following section provides a more realistic example of
	what would happen in a normal browser to browser connection.		what would happen in a normal browser to browser connection.
	The flow shows Alice's browser initiating the session to Bob's		The flow shows Alice's browser initiating the session to Bob's
	browser. The messages from Alice's JS to Bob's JS are assumed to		browser. The messages from Alice's JS to Bob's JS are assumed to
	flow over some signaling protocol via a web server. The JS on both		flow over some signaling protocol via a web server. The JS on both
	Alice's side and Bob's side waits for all candidates before sending		Alice's side and Bob's side waits for all candidates before sending
	skipping to change at page 68, line 31 ¶		skipping to change at page 70, line 31 ¶
	a=ice-ufrag:ETEn1v9DoTMB9J4r		a=ice-ufrag:ETEn1v9DoTMB9J4r
	a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl		a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl
	a=fingerprint:sha-256		a=fingerprint:sha-256
	19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04		19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
	:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2		:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
	a=setup:actpass		a=setup:actpass
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level		a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
	a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid		a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
	a=ssrc:1732846380 cname:EocUG1f0fcg/yvY7
	a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500		a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500
	typ host		typ host
	a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501		a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501
	typ host		typ host
	a=end-of-candidates		a=end-of-candidates
	m=video 56502 UDP/TLS/RTP/SAVPF 100 101		m=video 56502 UDP/TLS/RTP/SAVPF 100 101
	c=IN IP4 192.0.2.1		c=IN IP4 192.0.2.1
	a=rtcp:56503 IN IP4 192.0.2.1		a=rtcp:56503 IN IP4 192.0.2.1
	a=mid:v1		a=mid:v1
	skipping to change at page 69, line 4 ¶		skipping to change at page 70, line 51 ¶
	a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae		a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
	f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0		f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
	a=sendrecv		a=sendrecv
	a=rtpmap:100 VP8/90000		a=rtpmap:100 VP8/90000
	a=rtpmap:101 rtx/90000		a=rtpmap:101 rtx/90000
	a=fmtp:101 apt=100		a=fmtp:101 apt=100
	a=ice-ufrag:BGKkWnG5GmiUpdIV		a=ice-ufrag:BGKkWnG5GmiUpdIV
	a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf		a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf
	a=fingerprint:sha-256		a=fingerprint:sha-256
	19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04		19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
	:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2		:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
	a=setup:actpass		a=setup:actpass
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid		a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
	a=rtcp-fb:100 ccm fir		a=rtcp-fb:100 ccm fir
	a=rtcp-fb:100 nack		a=rtcp-fb:100 nack
	a=rtcp-fb:100 nack pli		a=rtcp-fb:100 nack pli
	a=ssrc:1366781083 cname:EocUG1f0fcg/yvY7
	a=ssrc:1366781084 cname:EocUG1f0fcg/yvY7
	a=ssrc-group:FID 1366781083 1366781084
	a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56502		a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56502
	typ host		typ host
	a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503		a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503
	typ host		typ host
	a=end-of-candidates		a=end-of-candidates
	The SDP for |answer-A1| looks like:		The SDP for |answer-A1| looks like:
	v=0		v=0
	o=- 6729291447651054566 1 IN IP4 0.0.0.0		o=- 6729291447651054566 1 IN IP4 0.0.0.0
	skipping to change at page 69, line 50 ¶		skipping to change at page 71, line 46 ¶
	a=rtpmap:98 telephone-event/48000		a=rtpmap:98 telephone-event/48000
	a=maxptime:120		a=maxptime:120
	a=ice-ufrag:6sFvz2gdLkEwjZEr		a=ice-ufrag:6sFvz2gdLkEwjZEr
	a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2		a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
	a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35		a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
	:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08		:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
	a=setup:active		a=setup:active
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level		a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
	a=ssrc:3429951804 cname:Q/NWs1ao1HmN4Xa5
	a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000		a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000
	typ host		typ host
	a=end-of-candidates		a=end-of-candidates
	m=video 20000 UDP/TLS/RTP/SAVPF 100 101		m=video 20000 UDP/TLS/RTP/SAVPF 100 101
	c=IN IP4 192.0.2.2		c=IN IP4 192.0.2.2
	a=rtcp 20001 IN IP4 192.0.2.2		a=rtcp 20001 IN IP4 192.0.2.2
	a=mid:v1		a=mid:v1
	a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1		a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
	PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0		PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0
	skipping to change at page 70, line 26 ¶		skipping to change at page 72, line 21 ¶
	a=rtpmap:101 rtx/90000		a=rtpmap:101 rtx/90000
	a=fmtp:101 apt=100		a=fmtp:101 apt=100
	a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35		a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
	:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08		:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
	a=setup:active		a=setup:active
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	a=rtcp-fb:100 ccm fir		a=rtcp-fb:100 ccm fir
	a=rtcp-fb:100 nack		a=rtcp-fb:100 nack
	a=rtcp-fb:100 nack pli		a=rtcp-fb:100 nack pli
	a=ssrc:3229706345 cname:Q/NWs1ao1HmN4Xa5
	a=ssrc:3229706346 cname:Q/NWs1ao1HmN4Xa5
	a=ssrc-group:FID 3229706345 3229706346
	8.2. Normal Examples		7.2. Normal Examples
	This section shows a typical example of a session between two		This section shows a typical example of a session between two
	browsers setting up an audio channel and a data channel. Trickle ICE		browsers setting up an audio channel and a data channel. Trickle ICE
	is used in full trickle mode with a bundle policy of max-bundle, an		is used in full trickle mode with a bundle policy of max-bundle, an
	RTCP mux policy of require, and a single TURN server. Later, two		RTCP mux policy of require, and a single TURN server. Later, two
	video flows, one for the presenter and one for screen sharing, are		video flows, one for the presenter and one for screen sharing, are
	added to the session. This example shows Alice's browser initiating		added to the session. This example shows Alice's browser initiating
	the session to Bob's browser. The messages from Alice's JS to Bob's		the session to Bob's browser. The messages from Alice's JS to Bob's
	JS are assumed to flow over some signaling protocol via a web server.		JS are assumed to flow over some signaling protocol via a web server.
	skipping to change at page 73, line 34 ¶		skipping to change at page 75, line 34 ¶
	a=ice-ufrag:ATEn1v9DoTMB9J4r		a=ice-ufrag:ATEn1v9DoTMB9J4r
	a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl		a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
	a=fingerprint:sha-256		a=fingerprint:sha-256
	19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04		19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
	:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2		:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
	a=setup:actpass		a=setup:actpass
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level		a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
	a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid		a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
	a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
	m=application 0 UDP/DTLS/SCTP webrtc-datachannel		m=application 0 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP4 0.0.0.0		c=IN IP4 0.0.0.0
	a=bundle-only		a=bundle-only
	a=mid:d1		a=mid:d1
	a=fmtp:webrtc-datachannel max-message-size=65536		a=fmtp:webrtc-datachannel max-message-size=65536
	a=sctp-port 5000		a=sctp-port 5000
	a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04		a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
	:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2		:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
	a=setup:actpass		a=setup:actpass
	skipping to change at page 75, line 33 ¶		skipping to change at page 76, line 38 ¶
	a=maxptime:120		a=maxptime:120
	a=ice-ufrag:7sFvz2gdLkEwjZEr		a=ice-ufrag:7sFvz2gdLkEwjZEr
	a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2		a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
	a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35		a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
	:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08		:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
	a=setup:active		a=setup:active
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level		a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
	a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid		a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
	a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
	m=application 9 UDP/DTLS/SCTP webrtc-datachannel		m=application 9 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP4 0.0.0.0		c=IN IP4 0.0.0.0
	a=mid:d1		a=mid:d1
	a=fmtp:webrtc-datachannel max-message-size=65536		a=fmtp:webrtc-datachannel max-message-size=65536
	a=sctp-port 5000		a=sctp-port 5000
	a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35		a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
	:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08		:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
	a=setup:active		a=setup:active
	skipping to change at page 76, line 40 ¶		skipping to change at page 77, line 44 ¶
	a=maxptime:120		a=maxptime:120
	a=ice-ufrag:7sFvz2gdLkEwjZEr		a=ice-ufrag:7sFvz2gdLkEwjZEr
	a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2		a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
	a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35		a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
	:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08		:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
	a=setup:actpass		a=setup:actpass
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level		a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
	a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid		a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
	a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
	a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host		a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
	a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx		a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
	raddr 192.168.2.3 rport 61665		raddr 192.168.2.3 rport 61665
	a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay		a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
	raddr 55.66.77.88 rport 64532		raddr 55.66.77.88 rport 64532
	a=end-of-candidates		a=end-of-candidates
	m=application 64532 UDP/DTLS/SCTP webrtc-datachannel		m=application 64532 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP4 55.66.77.88		c=IN IP4 55.66.77.88
	a=mid:d1		a=mid:d1
	a=fmtp:webrtc-datachannel max-message-size=65536		a=fmtp:webrtc-datachannel max-message-size=65536
	a=sctp-port 5000		a=sctp-port 5000
	a=ice-ufrag:7sFvz2gdLkEwjZEr		a=ice-ufrag:7sFvz2gdLkEwjZEr
	a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2		a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
	a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35		a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
	skipping to change at page 77, line 39 ¶		skipping to change at page 78, line 45 ¶
	a=fingerprint:sha-256		a=fingerprint:sha-256
	19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04		19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
	:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2		:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
	a=setup:actpass		a=setup:actpass
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid		a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
	a=rtcp-fb:100 ccm fir		a=rtcp-fb:100 ccm fir
	a=rtcp-fb:100 nack		a=rtcp-fb:100 nack
	a=rtcp-fb:100 nack pli		a=rtcp-fb:100 nack pli
	a=ssrc:1366781083 cname:Q/NWs1ao1HmN4Xa5
	a=ssrc:1366781084 cname:Q/NWs1ao1HmN4Xa5
	a=ssrc-group:FID 1366781083 1366781084
	m=video 0 UDP/TLS/RTP/SAVPF 100 101		m=video 0 UDP/TLS/RTP/SAVPF 100 101
	c=IN IP4 55.66.77.88		c=IN IP4 55.66.77.88
	a=bundle-only		a=bundle-only
	a=rtcp:64532 IN IP4 55.66.77.88		a=rtcp:64532 IN IP4 55.66.77.88
	a=mid:v1		a=mid:v1
	a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae		a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae
	f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0		f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
	a=sendrecv		a=sendrecv
	a=rtpmap:100 VP8/90000		a=rtpmap:100 VP8/90000
	a=rtpmap:101 rtx/90000		a=rtpmap:101 rtx/90000
	a=fmtp:101 apt=100		a=fmtp:101 apt=100
	a=fingerprint:sha-256		a=fingerprint:sha-256
	19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04		19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
	:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2		:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
	a=setup:actpass		a=setup:actpass
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	skipping to change at page 78, line 16 ¶		skipping to change at page 79, line 19 ¶
	a=fingerprint:sha-256		a=fingerprint:sha-256
	19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04		19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
	:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2		:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
	a=setup:actpass		a=setup:actpass
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid		a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
	a=rtcp-fb:100 ccm fir		a=rtcp-fb:100 ccm fir
	a=rtcp-fb:100 nack		a=rtcp-fb:100 nack
	a=rtcp-fb:100 nack pli		a=rtcp-fb:100 nack pli
	a=ssrc:2366781083 cname:Q/NWs1ao1HmN4Xa5
	a=ssrc:2366781084 cname:Q/NWs1ao1HmN4Xa5
	a=ssrc-group:FID 2366781083 2366781084
	The SDP for |answer-B2| looks like: (note the use of setup:passive to		The SDP for |answer-B2| looks like: (note the use of setup:passive to
	maintain the existing DTLS roles, and the use of a=recvonly to		maintain the existing DTLS roles, and the use of a=recvonly to
	indicate that the video streams are one-way)		indicate that the video streams are one-way)
	v=0		v=0
	o=- 4962303333179871723 2 IN IP4 0.0.0.0		o=- 4962303333179871723 2 IN IP4 0.0.0.0
	s=-		s=-
	t=0 0		t=0 0
	a=group:BUNDLE a1 d1 v1 v2		a=group:BUNDLE a1 d1 v1 v2
	skipping to change at page 79, line 7 ¶		skipping to change at page 80, line 6 ¶
	a=ice-ufrag:ATEn1v9DoTMB9J4r		a=ice-ufrag:ATEn1v9DoTMB9J4r
	a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl		a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
	a=fingerprint:sha-256		a=fingerprint:sha-256
	19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04		19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
	:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2		:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
	a=setup:passive		a=setup:passive
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level		a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
	a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid		a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
	a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
	a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host		a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
	a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx		a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
	raddr 192.168.1.2 rport 51556		raddr 192.168.1.2 rport 51556
	a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay		a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
	raddr 11.22.33.44 rport 52546		raddr 11.22.33.44 rport 52546
	a=end-of-candidates		a=end-of-candidates
	m=application 52546 UDP/DTLS/SCTP webrtc-datachannel		m=application 52546 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP4 11.22.33.44		c=IN IP4 11.22.33.44
	a=mid:d1		a=mid:d1
	skipping to change at page 80, line 6 ¶		skipping to change at page 81, line 4 ¶
	c=IN IP4 11.22.33.44		c=IN IP4 11.22.33.44
	a=rtcp:52546 IN IP4 11.22.33.44		a=rtcp:52546 IN IP4 11.22.33.44
	a=mid:v2		a=mid:v2
	a=recvonly		a=recvonly
	a=rtpmap:100 VP8/90000		a=rtpmap:100 VP8/90000
	a=rtpmap:101 rtx/90000		a=rtpmap:101 rtx/90000
	a=fmtp:101 apt=100		a=fmtp:101 apt=100
	a=fingerprint:sha-256		a=fingerprint:sha-256
	19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04		19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
	:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2		:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
	a=setup:passive		a=setup:passive
	a=rtcp-mux		a=rtcp-mux
	a=rtcp-rsize		a=rtcp-rsize
	a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid		a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
	a=rtcp-fb:100 ccm fir		a=rtcp-fb:100 ccm fir
	a=rtcp-fb:100 nack		a=rtcp-fb:100 nack
	a=rtcp-fb:100 nack pli		a=rtcp-fb:100 nack pli
	9. Security Considerations		8. Security Considerations
	The IETF has published separate documents		The IETF has published separate documents
	[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing		[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing
	the security architecture for WebRTC as a whole. The remainder of		the security architecture for WebRTC as a whole. The remainder of
	this section describes security considerations for this document.		this section describes security considerations for this document.
	While formally the JSEP interface is an API, it is better to think of		While formally the JSEP interface is an API, it is better to think of
	it is an Internet protocol, with the JS being untrustworthy from the		it is an Internet protocol, with the JS being untrustworthy from the
	perspective of the browser. Thus, the threat model of [RFC3552]		perspective of the browser. Thus, the threat model of [RFC3552]
	applies. In particular, JS can call the API in any order and with		applies. In particular, JS can call the API in any order and with
	skipping to change at page 80, line 43 ¶		skipping to change at page 81, line 42 ¶
	does not have complete control of browser behavior. One case that		does not have complete control of browser behavior. One case that
	bears particular mention is that editing ICE candidates out of the		bears particular mention is that editing ICE candidates out of the
	SDP or suppressing trickled candidates does not have the expected		SDP or suppressing trickled candidates does not have the expected
	behavior: implementations will still perform checks from those		behavior: implementations will still perform checks from those
	candidates even if they are not sent to the other side. Thus, for		candidates even if they are not sent to the other side. Thus, for
	instance, it is not possible to prevent the remote peer from learning		instance, it is not possible to prevent the remote peer from learning
	your public IP address by removing server reflexive candidates.		your public IP address by removing server reflexive candidates.
	Applications which wish to conceal their public IP address should		Applications which wish to conceal their public IP address should
	instead configure the ICE agent to use only relay candidates.		instead configure the ICE agent to use only relay candidates.
	10. IANA Considerations		9. IANA Considerations
	This document requires no actions from IANA.		This document requires no actions from IANA.
	11. Acknowledgements		10. Acknowledgements
	Significant text incorporated in the draft as well and review was		Significant text incorporated in the draft as well and review was
	provided by Peter Thatcher, Taylor Brandstetter, Harald Alvestrand		provided by Peter Thatcher, Taylor Brandstetter, Harald Alvestrand
	and Suhas Nandakumar. Dan Burnett, Neil Stratford, Anant Narayanan,		and Suhas Nandakumar. Dan Burnett, Neil Stratford, Anant Narayanan,
	Andrew Hutton, Richard Ejzak, Adam Bergkvist and Matthew Kaufman all		Andrew Hutton, Richard Ejzak, Adam Bergkvist and Matthew Kaufman all
	provided valuable feedback on this proposal.		provided valuable feedback on this proposal.
	12. References		11. References
	12.1. Normative References		11.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 (RID) Source Description (SDES)", draft-ietf-		Identifier (RID) Source Description (SDES)", draft-ietf-
	avtext-rid-00 (work in progress), February 2016.		avtext-rid-00 (work in progress), February 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".		Protocol".
	[I-D.ietf-mmusic-4572-update]		[I-D.ietf-mmusic-4572-update]
	Holmberg, C., "Updates to RFC 4572", draft-ietf-mmusic-		Holmberg, C., "Updates to RFC 4572", draft-ietf-mmusic-
	4572-update-05 (work in progress), June 2016.		4572-update-05 (work in progress), June 2016.
			[I-D.ietf-mmusic-dtls-sdp]
			Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer
			Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-14 (work
			in progress), July 2016.
	[I-D.ietf-mmusic-msid]		[I-D.ietf-mmusic-msid]
	Alvestrand, H., "Cross Session Stream Identification in		Alvestrand, H., "Cross Session Stream Identification in
	the Session Description Protocol", draft-ietf-mmusic-		the Session Description Protocol", draft-ietf-mmusic-
	msid-01 (work in progress), August 2013.		msid-01 (work in progress), August 2013.
	[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-08 (work in progress), June 2016.		exclusive-08 (work in progress), June 2016.
	skipping to change at page 84, line 30 ¶		skipping to change at page 85, line 30 ¶
	Attributes in the Session Description Protocol (SDP)",		Attributes in the Session Description Protocol (SDP)",
	RFC 6236, May 2011.		RFC 6236, May 2011.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.		Security Version 1.2", RFC 6347, January 2012.
	[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure		[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
	Real-time Transport Protocol (SRTP)", RFC 6904, April		Real-time Transport Protocol (SRTP)", RFC 6904, April
	2013.		2013.
	12.2. Informative References		11.2. Informative References
	[I-D.ietf-rtcweb-ip-handling]		[I-D.ietf-rtcweb-ip-handling]
	Uberti, J. and G. Shieh, "WebRTC IP Address Handling		Uberti, J. and G. Shieh, "WebRTC IP Address Handling
	Recommendations", draft-ietf-rtcweb-ip-handling-01 (work		Recommendations", draft-ietf-rtcweb-ip-handling-01 (work
	in progress), March 2016.		in progress), March 2016.
	[I-D.nandakumar-rtcweb-sdp]		[I-D.nandakumar-rtcweb-sdp]
	Nandakumar, S. and C. Jennings, "SDP for the WebRTC",		Nandakumar, S. and C. Jennings, "SDP for the WebRTC",
	draft-nandakumar-rtcweb-sdp-02 (work in progress), July		draft-nandakumar-rtcweb-sdp-02 (work in progress), July
	2013.		2013.
	skipping to change at page 85, line 13 ¶		skipping to change at page 86, line 13 ¶
	RFC 3960, December 2004.		RFC 3960, December 2004.
	[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session		[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
	Description Protocol (SDP) Security Descriptions for Media		Description Protocol (SDP) Security Descriptions for Media
	Streams", RFC 4568, July 2006.		Streams", RFC 4568, July 2006.
	[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.		[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
	Hakenberg, "RTP Retransmission Payload Format", RFC 4588,		Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
	July 2006.		July 2006.
			[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
			Digits, Telephony Tones, and Telephony Signals", RFC 4733,
			DOI 10.17487/RFC4733, December 2006,
			<http://www.rfc-editor.org/info/rfc4733>.
	[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size		[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
	Real-Time Transport Control Protocol (RTCP): Opportunities		Real-Time Transport Control Protocol (RTCP): Opportunities
	and Consequences", RFC 5506, April 2009.		and Consequences", RFC 5506, April 2009.
	[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific		[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
	Media Attributes in the Session Description Protocol		Media Attributes in the Session Description Protocol
	(SDP)", RFC 5576, June 2009.		(SDP)", RFC 5576, June 2009.
	[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
	for Establishing a Secure Real-time Transport Protocol		for Establishing a Secure Real-time Transport Protocol
	(SRTP) Security Context Using Datagram Transport Layer		(SRTP) Security Context Using Datagram Transport Layer
	Security (DTLS)", RFC 5763, May 2010.		Security (DTLS)", RFC 5763, May 2010.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer		[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure		Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.		Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
	[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
	the Session Description Protocol", RFC 5956, September
	2010.
	[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time		[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
	Transport Protocol (RTP) Header Extension for Client-to-		Transport Protocol (RTP) Header Extension for Client-to-
	Mixer Audio Level Indication", RFC 6464,		Mixer Audio Level Indication", RFC 6464,
	DOI 10.17487/RFC6464, December 2011,		DOI 10.17487/RFC6464, December 2011,
	<http://www.rfc-editor.org/info/rfc6464>.		<http://www.rfc-editor.org/info/rfc6464>.
	[W3C.WD-webrtc-20140617]		[W3C.WD-webrtc-20140617]
	Bergkvist, A., Burnett, D., Narayanan, A., and C.		Bergkvist, A., Burnett, D., Narayanan, A., and C.
	Jennings, "WebRTC 1.0: Real-time Communication Between		Jennings, "WebRTC 1.0: Real-time Communication Between
	Browsers", World Wide Web Consortium WD WD-webrtc-		Browsers", World Wide Web Consortium WD WD-webrtc-
	20140617, June 2014,		20140617, June 2014,
	<http://www.w3.org/TR/2011/WD-webrtc-20140617>.		<http://www.w3.org/TR/2011/WD-webrtc-20140617>.
	Appendix A. Change log		Appendix A. Appendix A
			For the syntax validation performed in Section 5.7, the following
			list of ABNF definitions is used:
			+-----------------------+-------------------------------------------+
			| Attribute | Reference |
			+-----------------------+-------------------------------------------+
			| ptime | [RFC4566] Section 9 |
			| maxptime | [RFC4566] Section 9 |
			| rtpmap | [RFC4566] Section 9 |
			| recvonly | [RFC4566] Section 9 |
			| sendrecv | [RFC4566] Section 9 |
			| sendonly | [RFC4566] Section 9 |
			| inactive | [RFC4566] Section 9 |
			| framerate | [RFC4566] Section 9 |
			| fmtp | [RFC4566] Section 9 |
			| quality | [RFC4566] Section 9 |
			| rtcp | [RFC3605] Section 2.1 |
			| setup | [RFC4145] Sections 3, 4, and 5 |
			| connection | [RFC4145] Sections 3, 4, and 5 |
			| fingerprint | [RFC4572] Section 5 |
			| rtcp-fb | [RFC4585] Section 4.2 |
			| candidate | [RFC5245] Section 15.1 |
			| remote-candidates | [RFC5245] Section 15.2 |
			| ice-lite | [RFC5245] Section 15.3 |
			| ice-ufrag | [RFC5245] Section 15.4 |
			| ice-pwd | [RFC5245] Section 15.4 |
			| ice-options | [RFC5245] Section 15.5 |
			| extmap | [RFC5285] Section 7 |
			| mid | [RFC5888] Section 4 and 5 |
			| group | [RFC5888] Section 4 and 5 |
			| imageattr | [RFC6236] Section 3.1 |
			| extmap (encrypt | [RFC6904] Section 4 |
			| option) | |
			| msid | [I-D.ietf-mmusic-msid] Section 2 |
			| rid | [I-D.ietf-mmusic-rid] Section 10 |
			| simulcast | [I-D.ietf-mmusic-sdp-simulcast]Section |
			| | 6.1 |
			| dtls-id | [I-D.ietf-mmusic-dtls-sdp]Section 4 |
			+-----------------------+-------------------------------------------+
			Table 1: SDP ABNF References
			Appendix B. Change log
	Note: This section will be removed by RFC Editor before publication.		Note: This section will be removed by RFC Editor before publication.
			Changes in draft-17:
			o Split createOffer and createAnswer sections to clearly indicate
			attributes which always appear and which only appear when not
			bundled into another m= section.
			o Add descriptions of RtpTransceiver methods.
			o Describe how to process RTCP feedback attributes.
			o Clarify transceiver directions and their interaction with 3264.
			o Describe setCodecPreferences.
			o Update RTP demux algorithm. Include RTCP.
			o Update requirements for when a=rtcp is included, limiting to cases
			where it is needed for backward compatibility.
			o Clarify SAR handling.
			o Updated addTrack matching algorithm.
			o Remove a=ssrc requirements.
			o Handle a=setup in reoffers.
			o Discuss how RTX/FEC should be handled.
			o Discuss how telephone-event should be handled.
			o Discuss how CN/DTX should be handled.
			o Add missing references to ABNF table.
	Changes in draft-16:		Changes in draft-16:
	o Update addIceCandidate to indicate ICE generation and allow per-m=		o Update addIceCandidate to indicate ICE generation and allow per-m=
	section end-of-candidates.		section end-of-candidates.
	o Update fingerprint handling to use draft-ietf-mmusic-4572-update.		o Update fingerprint handling to use draft-ietf-mmusic-4572-update.
	o Update text around SDP processing of RTP header extensions and		o Update text around SDP processing of RTP header extensions and
	payload formats.		payload formats.
End of changes. 115 change blocks.
	370 lines changed or deleted		554 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/