Diff: draft-ietf-rtcweb-jsep-11.txt - draft-ietf-rtcweb-jsep-12.txt

	draft-ietf-rtcweb-jsep-11.txt	draft-ietf-rtcweb-jsep-12.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: January 6, 2016 Cisco	Expires: April 20, 2016 Cisco
	E. Rescorla, Ed.	E. Rescorla, Ed.
	Mozilla	Mozilla

	July 5, 2015	October 18, 2015

	Javascript Session Establishment Protocol	Javascript Session Establishment Protocol

	draft-ietf-rtcweb-jsep-11	draft-ietf-rtcweb-jsep-12

	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 January 6, 2016.	This Internet-Draft will expire on April 20, 2016.

	Copyright Notice	Copyright Notice

	Copyright (c) 2015 IETF Trust and the persons identified as the	Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents	Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of	(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents	publication of this document. Please review these documents

	skipping to change at page 2, line 35	skipping to change at page 2, line 35
	3.5.2. Interpreting an imageattr Attribute . . . . . . . . . 14	3.5.2. Interpreting an imageattr Attribute . . . . . . . . . 14
	3.6. Interactions With Forking . . . . . . . . . . . . . . . . 15	3.6. Interactions With Forking . . . . . . . . . . . . . . . . 15
	3.6.1. Sequential Forking . . . . . . . . . . . . . . . . . 15	3.6.1. Sequential Forking . . . . . . . . . . . . . . . . . 15
	3.6.2. Parallel Forking . . . . . . . . . . . . . . . . . . 16	3.6.2. Parallel Forking . . . . . . . . . . . . . . . . . . 16
	4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 17	4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 17	4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 17	4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 17
	4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 19	4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 19
	4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 20	4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 20
	4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 21	4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 21

	4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 21	4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 22
	4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 22	4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 22
	4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 23	4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 23

	4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 23	4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 24
	4.1.7. localDescription . . . . . . . . . . . . . . . . . . 24	4.1.7. localDescription . . . . . . . . . . . . . . . . . . 24
	4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 24	4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 24
	4.1.9. canTrickleIceCandidates . . . . . . . . . . . . . . . 24	4.1.9. canTrickleIceCandidates . . . . . . . . . . . . . . . 24
	4.1.10. setConfiguration . . . . . . . . . . . . . . . . . . 25	4.1.10. setConfiguration . . . . . . . . . . . . . . . . . . 25
	4.1.11. addIceCandidate . . . . . . . . . . . . . . . . . . . 26	4.1.11. addIceCandidate . . . . . . . . . . . . . . . . . . . 26
	5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 26	5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 26
	5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 26	5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 26
	5.1.1. Implementation Requirements . . . . . . . . . . . . . 26	5.1.1. Implementation Requirements . . . . . . . . . . . . . 26
	5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 28	5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 28
	5.1.3. Profile Names and Interoperability . . . . . . . . . 28	5.1.3. Profile Names and Interoperability . . . . . . . . . 28
	5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 29	5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 29
	5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 29	5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 29
	5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 34	5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 34
	5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 37	5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 37
	5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 37	5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 37

	5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 37	5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 38
	5.2.3.3. IceRestart . . . . . . . . . . . . . . . . . . . 38	5.2.3.3. IceRestart . . . . . . . . . . . . . . . . . . . 38
	5.2.3.4. VoiceActivityDetection . . . . . . . . . . . . . 38	5.2.3.4. VoiceActivityDetection . . . . . . . . . . . . . 38

	5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 38	5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 39
	5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 39	5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 39
	5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 43	5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 43
	5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 44	5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 44

	5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 44	5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 45
	5.4. Processing a Local Description . . . . . . . . . . . . . 44	5.4. Processing a Local Description . . . . . . . . . . . . . 45
	5.5. Processing a Remote Description . . . . . . . . . . . . . 45	5.5. Processing a Remote Description . . . . . . . . . . . . . 45

	5.6. Parsing a Session Description . . . . . . . . . . . . . . 45	5.6. Parsing a Session Description . . . . . . . . . . . . . . 46
	5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 46	5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 46

	5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 47	5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 48
	5.6.3. Semantics Verification . . . . . . . . . . . . . . . 49	5.6.3. Semantics Verification . . . . . . . . . . . . . . . 49
	5.7. Applying a Local Description . . . . . . . . . . . . . . 50	5.7. Applying a Local Description . . . . . . . . . . . . . . 50

	5.8. Applying a Remote Description . . . . . . . . . . . . . . 50	5.8. Applying a Remote Description . . . . . . . . . . . . . . 51
	5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 50	5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 53
	6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 50	6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 54
	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 52	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 55
	7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 52	7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 56
	7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 56	7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 60
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 67	8. Security Considerations . . . . . . . . . . . . . . . . . . . 71
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 68	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 72
	11.1. Normative References . . . . . . . . . . . . . . . . . . 68	11.1. Normative References . . . . . . . . . . . . . . . . . . 72
	11.2. Informative References . . . . . . . . . . . . . . . . . 71	11.2. Informative References . . . . . . . . . . . . . . . . . 75
	Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 72	Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 76
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79

	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 15, line 6	skipping to change at page 15, line 6
	that it does not absolutely constrain the video formats that the	that it does not absolutely constrain the video formats that the
	sender can use, but gives an indication of the preferred values.	sender can use, but gives an indication of the preferred values.

	This specification prescribes more specific behavior. When a sender	This specification prescribes more specific behavior. When a sender
	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 first	resolution, receives an "a=imageattr recv" attribute, it MUST first
	check to see if the original resolution meets the criteria specified	check to see if the original resolution meets the criteria specified
	in the attribute, and transmit it untouched if so. If the original	in the attribute, and transmit it untouched if so. If the original
	resolution is too large for the attribute criteria, the sender SHOULD	resolution is too large for the attribute criteria, the sender SHOULD
	apply downscaling to the output of the MediaStreamTrack in order to	apply downscaling to the output of the MediaStreamTrack in order to

	satisfy the criteria. In rare cases, where a receiver requires a	satisfy the criteria.
	minimum resolution which is greater than the native resolution of the
	video, the sender SHOULD apply upscaling in order to provide that
	resolution. The sender SHOULD NOT apply upscaling in any other
	cases.


	If there is no appropriate scaling mechanism that allows the received	If the receiver requires a minimum resolution which is greater than
	criteria to be satisfied, the sender MUST NOT transmit the track.	the native resolution of the video, upscaling is needed, but this may
		not be appropriate in all cases. To address this concern, the
		application can set an upscaling policy for each sent track. For
		this case, if upscaling is permitted by policy, the sender SHOULD
		apply upscaling in order to provide the desired resolution.
		Otherwise, the sender MUST NOT apply upscaling. The sender SHOULD
		NOT upscale in other cases, even if the policy permits it.

		If there is no appropriate and permitted scaling mechanism that
		allows the received criteria to be satisfied, 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.6. Interactions With Forking	3.6. Interactions With Forking

	Some call signaling systems allow various types of forking where an	Some call signaling systems allow various types of forking where an
	SDP Offer may be provided to more than one device. For example, SIP	SDP Offer may be provided to more than one device. For example, SIP
	[RFC3261] defines both a "Parallel Search" and "Sequential Search".	[RFC3261] defines both a "Parallel Search" and "Sequential Search".
	Although these are primarily signaling level issues that are outside	Although these are primarily signaling level issues that are outside

	skipping to change at page 28, line 47	skipping to change at page 29, line 6
	follow the following rules when processing the media m= sections in	follow the following rules when processing the media m= sections in
	an offer:	an offer:

	o The profile in any "m=" line in any answer MUST exactly match the	o The profile in any "m=" line in any answer MUST exactly match the
	profile provided in the offer.	profile provided in the offer.

	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 the	effect; support for DTLS-SRTP is determined by the presence of one
	"a=fingerprint" attribute. Note that lack of an "a=fingerprint"	or more "a=fingerprint" attribute. Note that lack of an
	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.

	skipping to change at page 31, line 22	skipping to change at page 31, line 27
	indicated in [I-D.ietf-mmusic-trickle-ice], Section 5.1.	indicated in [I-D.ietf-mmusic-trickle-ice], 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 the	specified in[I-D.nandakumar-mmusic-proto-iana-registration] if the
	default candidate uses TCP transport.	default candidate uses TCP transport.

	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 IP6 ::",	gathered, the "c=" line must contain the "dummy" value "IN IP4
	as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1.	0.0.0.0", as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1.
		[[NOTE: This has not yet changed in the trickle ICE draft.]]

	Each m= section MUST include the following attribute lines:	Each m= section MUST include the following attribute lines:

	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,	o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,

	containing the dummy value "9 IN IP6 ::", because no candidates	containing the dummy value "9 IN IP4 0.0.0.0", because no
	have yet been gathered.	candidates have yet been gathered.

	o An "a=msid" line, as specified in [I-D.ietf-mmusic-msid],	o An "a=msid" line, as specified in [I-D.ietf-mmusic-msid],
	Section 2.	Section 2.

	o An "a=sendrecv" line, as specified in [RFC3264], Section 5.1.	o An "a=sendrecv" line, as specified in [RFC3264], Section 5.1.

	o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as	o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as
	specified in [RFC4566], Section 6. The audio and video codecs	specified in [RFC4566], Section 6. The audio and video codecs
	that MUST be supported are specified in [I-D.ietf-rtcweb-audio]	that MUST be supported are specified in [I-D.ietf-rtcweb-audio]
	(see Section 3) and [I-D.ietf-rtcweb-video] (see Section 5).	(see Section 3) and [I-D.ietf-rtcweb-video] (see Section 5).

	skipping to change at page 32, line 27	skipping to change at page 32, line 32
	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],	o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245],
	Section 15.4.	Section 15.4.

	o An "a=ice-options" line, with the "trickle" option, as specified	o An "a=ice-options" line, with the "trickle" option, as specified
	in [I-D.ietf-mmusic-trickle-ice], Section 4.	in [I-D.ietf-mmusic-trickle-ice], Section 4.


	o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the	o An "a=fingerprint" line for each of the endpoint's certificates,
	algorithm used for the fingerprint MUST match that used in the	as specified in [RFC4572], Section 5; the digest algorithm used
	certificate signature.	for the fingerprint MUST match that used in the certificate
		signature.

	o An "a=setup" line, as specified in [RFC4145], Section 4, and	o An "a=setup" line, as specified in [RFC4145], Section 4, and
	clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.	clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
	The role value in the offer MUST be "actpass".	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" line, as specified in [RFC5761], Section 5.1.1.

	o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5.	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

	skipping to change at page 33, line 29	skipping to change at page 33, line 37
	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.

	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 the SCTP port number, as specified in	value MUST be set to "webrtc-datachannel" as specified in
	Section 4.1. [TODO: update this to use a=sctp-port, as indicated in	[I-D.ietf-mmusic-sctp-sdp], Section 4.1.
	the latest data channel docs]

	Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-	Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-
	passwd", "a=ice-options", "a=candidate", "a=fingerprint", and	passwd", "a=ice-options", "a=candidate", "a=fingerprint", and
	"a=setup" lines MUST be included as mentioned above, along with an	"a=setup" lines MUST be included as mentioned above, along with an

	"a=sctpmap" line referencing the SCTP port number and specifying the	"a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line
	application protocol indicated in [I-D.ietf-rtcweb-data-protocol].	referencing the SCTP port number as defined in
	[OPEN ISSUE: the -01 of this document is missing this information.]	[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
	in [RFC5888], Section 7. For each MediaStream with more than one	in [RFC5888], Section 7. For each MediaStream with more than one

	skipping to change at page 35, line 7	skipping to change at page 35, line 12
	If the initial offer was applied using setLocalDescription, but an	If the initial offer was applied using setLocalDescription, but an
	answer from the remote side has not yet been applied, meaning the	answer from the remote side has not yet been applied, meaning the
	PeerConnection is still in the "local-offer" state, an offer is	PeerConnection is still in the "local-offer" state, an offer is
	generated by following the steps in the "stable" state above, along	generated by following the steps in the "stable" state above, along
	with these exceptions:	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, 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. Each "a=rtcp" attribute line	described in [RFC5245], Section 4.3. If ICE checking has already
	MUST also be filled in with the port and address of the	completed for one or more candidate pairs and a candidate pair is
	appropriate default candidate, either the default RTP or RTCP	in active use, then that pair MUST be used, even if ICE has not
	candidate, depending on whether RTCP multiplexing is currently	yet completed. Note that this differs from the guidance in
	active or not. Note that if RTCP multiplexing is being offered,	[RFC5245], Section 9.1.2.2, which only refers to offers created
	but not yet active, the default RTCP candidate MUST be used, as	when ICE has completed. Each "a=rtcp" attribute line MUST also be
	indicated in [RFC5761], section 5.1.3. In each case, if no	filled in with the port and address of the appropriate default
	candidates of the desired type have yet been gathered, dummy	candidate, either the default RTP or RTCP candidate, depending on
	values MUST be used, as described above.	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.3 was specified.	"IceRestart" option (Section 5.2.3.3 was specified.

	o Within each m= section, for each candidate that has been gathered	o Within each m= section, for each candidate that has been gathered
	during the most recent gathering phase (see Section 3.4.1), an	during the most recent gathering phase (see Section 3.4.1), an

	skipping to change at page 40, line 27	skipping to change at page 40, line 37
	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-mmusic-trickle-ice],	be used, as indicated in [I-D.ietf-mmusic-trickle-ice],
	Section 5.1.	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.

	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 IP6 ::",	gathered, the "c=" line must contain the "dummy" value "IN IP4
	as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1.	0.0.0.0", as defined in [I-D.ietf-mmusic-trickle-ice], 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 include the following:

	o If present in the offer, an "a=mid" line, as specified in	o If present in the offer, an "a=mid" line, as specified in
	[RFC5888], Section 9.1. The "mid" value MUST match that specified	[RFC5888], Section 9.1. The "mid" value MUST match that specified
	in the offer.	in the offer.

	o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,	o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,

	containing the dummy value "9 IN IP6 ::", because no candidates	containing the dummy value "9 IN IP4 0.0.0.0", because no
	have yet been gathered.	candidates have yet been gathered.

	o If a local MediaStreamTrack has been associated, an "a=msid" line,	o If a local MediaStreamTrack has been associated, an "a=msid" line,
	as specified in [I-D.ietf-mmusic-msid], Section 2.	as specified in [I-D.ietf-mmusic-msid], Section 2.

	o Depending on the directionality of the offer, the disposition of	o Depending on the directionality of the offer, the disposition of
	any associated remote MediaStreamTrack, and the presence of an	any associated remote MediaStreamTrack, and the presence of an
	associated local MediaStreamTrack, the appropriate directionality	associated local MediaStreamTrack, the appropriate directionality
	attribute, as specified in [RFC3264], Section 6.1. If the offer	attribute, as specified in [RFC3264], Section 6.1. If the offer
	was sendrecv, and the remote MediaStreamTrack is still "live", and	was sendrecv, and the remote MediaStreamTrack is still "live", and
	there is a local MediaStreamTrack that has been associated, the	there is a local MediaStreamTrack that has been associated, the

	skipping to change at page 41, line 46	skipping to change at page 42, line 9
	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-passwd" lines, as specified in [RFC5245],	o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245],
	Section 15.4.	Section 15.4.

	o If the "trickle" ICE option is present in the offer, an "a=ice-	o If the "trickle" ICE option is present in the offer, an "a=ice-
	options" line, with the "trickle" option, as specified in	options" line, with the "trickle" option, as specified in
	[I-D.ietf-mmusic-trickle-ice], Section 4.	[I-D.ietf-mmusic-trickle-ice], Section 4.


	o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the	o An "a=fingerprint" line for each of the endpoint's certificates,
	algorithm used for the fingerprint MUST match that used in the	as specified in [RFC4572], Section 5; the digest algorithm used
	certificate signature.	for the fingerprint MUST match that used in the certificate
		signature.

	o An "a=setup" line, as specified in [RFC4145], Section 4, and	o An "a=setup" line, as specified in [RFC4145], Section 4, and
	clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.	clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.


	The role value in the answer MUST be "active" or "passive"; the	The role value in the answer MUST be "active" or "passive"; the
	"active" role is RECOMMENDED.	"active" role is RECOMMENDED.

	o If present in the offer, an "a=rtcp-mux" line, as specified in	o If present in the offer, an "a=rtcp-mux" line, as specified in
	[RFC5761], Section 5.1.1. If the "require" RTCP multiplexing	[RFC5761], Section 5.1.1. If the "require" RTCP multiplexing
	policy is set and no "a=rtcp-mux" line is present in the offer,	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	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.	the m= line to zero, as indicated in [RFC3264], Section 6.

	o If present in the offer, an "a=rtcp-rsize" line, as specified in	o If present in the offer, an "a=rtcp-rsize" line, as specified in

	skipping to change at page 42, line 52	skipping to change at page 43, line 14

	o If a local MediaStreamTrack has been associated, and FEC has been	o If a local MediaStreamTrack has been associated, and FEC has been
	negotiated for this m= section, another "a=ssrc" line with the FEC	negotiated for this m= section, another "a=ssrc" line with the FEC
	SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR"	SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR"
	and including the primary and FEC SSRCs, as specified in	and including the primary and FEC SSRCs, as specified in
	[RFC5956], section 4.3. For simplicity, if both RTX and FEC are	[RFC5956], section 4.3. For simplicity, if both RTX and FEC are
	supported, the FEC SSRC MUST be the same as the RTX SSRC.	supported, the FEC SSRC MUST be the same as the RTX SSRC.

	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> field MUST be set to exactly match the	"application" and the <proto> and "fmt" fields MUST be set to exactly
	field in the offer; the "fmt" value MUST be set to the SCTP port	match the fields in the offer.
	number, as specified in Section 4.1. [TODO: update this to use
	a=sctp-port, as indicated in the latest data channel docs]

	Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-	Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-
	passwd", "a=ice-options", "a=candidate", "a=fingerprint", and	passwd", "a=ice-options", "a=candidate", "a=fingerprint", and
	"a=setup" lines MUST be included as mentioned above, along with an	"a=setup" lines MUST be included as mentioned above, along with an

	"a=sctpmap" line referencing the SCTP port number and specifying the	"a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line
	application protocol indicated in [I-D.ietf-rtcweb-data-protocol].	referencing the SCTP port number as defined in
	[OPEN ISSUE: the -01 of this document is missing this information.]	[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 46	skipping to change at page 50, line 10
	Assuming parsing completes successfully, the parsed description is	Assuming parsing completes successfully, the parsed description is
	then evaluated to ensure internal consistency as well as proper	then evaluated to ensure internal consistency as well as proper
	support for mandatory features. Specifically, the following checks	support for mandatory features. Specifically, the following checks
	are performed:	are performed:

	o For each m= section, valid values for each of the mandatory-to-use	o For each m= section, valid values for each of the mandatory-to-use
	features enumerated in Section 5.1.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	* ICE ufrag and password values, which MUST comply with the size
		limits specified in [RFC5245], Section 15.4.


	* DTLS fingerprint and setup values	* DTLS setup value, which MUST be set according to the rules
		specified in [RFC5763], Section 5, and MUST be consistent with
		the selected role of the current DTLS connection, if one
		exists.[TODO: may need revision, i.e., use of actpass

		* DTLS fingerprint values, where at least one fingerprint MUST be
		present.

		o Each m= section is also checked to ensure prohibited features are
		not used. If this is a local description, the "ice-lite"
		attribute MUST NOT be specified.

	If this session description is of type "pranswer" or "answer", the	If this session description is of type "pranswer" or "answer", the
	following additional checks are applied:	following additional checks are applied:

	o The session description must follow the rules defined in	o The session description must follow the rules defined in

	[RFC3264], Section 6.	[RFC3264], Section 6, including the requirement that the number of
		m= sections MUST exactly match the number of m= sections in the
		associated offer.


	o For each m= section, the protocol value MUST exactly match the	o For each m= section, the media type and protocol values MUST
	protocol value in the corresponding m= section in the associated	exactly match the media type and protocol values in the
	offer.	corresponding m= section in the associated offer.

	5.7. Applying a Local Description	5.7. Applying a Local Description

	The following steps are performed at the media engine level to apply	The following steps are performed at the media engine level to apply
	a local description.	a local description.

	First, the parsed parameters are checked to ensure that any	First, the parsed parameters are checked to ensure that any
	modifications performed fall within those explicitly permitted by	modifications performed fall within those explicitly permitted by
	Section 6; otherwise, processing MUST stop and an error MUST be	Section 6; otherwise, processing MUST stop and an error MUST be
	returned.	returned.

	Next, media sections are processed. For each media section, the	Next, media sections are processed. For each media section, the
	following steps MUST be performed; if any parameters are out of	following steps MUST be performed; if any parameters are out of
	bounds, or cannot be applied, processing MUST stop and an error MUST	bounds, or cannot be applied, processing MUST stop and an error MUST
	be returned.	be returned.


	o TODO	o If this media section is new, begin gathering candidates for it,
		as defined in [RFC5245], Section 4.1.1, unless it has been marked
		as bundle-only.

		o Or, if the ICE ufrag and password values have changed, trigger the
		ICE Agent to start an ICE restart and begin gathering new
		candidates for the media section, as defined in [RFC5245],
		Section 9.1.1.1, unless it has been marked as bundle-only.

		o If the media section proto value indicates use of RTP:

		* If RTCP mux is indicated, prepare to demux RTP and RTCP from
		the RTP ICE component, as specified in [RFC5761],
		Section 5.1.1. If RTCP mux is not indicated, but was indicated
		in a previous description, this MUST result in an error.

		* For each specified RTP header extension, establish a mapping
		between the extension ID and URI. If any indicated RTP header
		extension is unknown, this MUST result in an error. [TODO:
		ref]

		* If the MID header extension is supported, prepare to demux RTP
		data intended for this media section based on the MID header
		extension. [TODO: ref]

		* For each specified payload type, establish a mapping between
		the payload type ID and the actual media format. [TODO: ref]
		If any indicated payload type is unknown, this MUST result in
		an error.

		* For each specified "rtx" media format, establish a mapping
		between the RTX payload type and its associated primary payload
		type. [TODO: ref] If any referenced primary payload types are
		not present, this MUST result in an error.

		* If the directional attribute is of type "sendrecv" or
		"recvonly", enable receipt and decoding of media.

	Finally, if this description is of type "pranswer" or "answer",	Finally, if this description is of type "pranswer" or "answer",
	follow the processing defined in the Section 5.9 section below.	follow the processing defined in the Section 5.9 section below.

	5.8. Applying a Remote Description	5.8. Applying a Remote Description


	TODO	The following steps are performed at the media engine level to apply
		a remote description.

		For each media section, the following steps MUST be performed; if any
		parameters are out of bounds, or cannot be applied, processing MUST
		stop and an error MUST be returned.

		o If the description is of type "offer", and the ICE ufrag or
		password changed from the previous remote description, [TODO:
		ref], mark that an ICE restart is needed.

		o Configure the ICE components associated with this media section to
		use the supplied ICE remote ufrag and password for their
		connectivity checks.

		o Pair any supplied ICE candidates with any gathered local
		candidates, as described in [TODO: ref] and start connectivity
		checks with the appropriate credentials.

		o If the media section proto value indicates use of RTP:

		* [TODO: header extensions]

		* For each specified payload type that is also supported by the
		local implementation, establish a mapping between the payload
		type ID and the actual media format. [TODO: ref] If any
		indicated payload type is unknown, it MUST be ignored. [TODO:
		should fail on answers]

		* For each specified "rtx" media format, establish a mapping
		between the RTX payload type and its associated primary payload
		type. [TODO: ref] If any referenced primary payload types are
		not present, this MUST result in an error.

		* For each specified fmtp parameter that is supported by the
		local implementation, enable them on the associated payload
		types.

		* For each specified RTCP feedback mechanism that is supported by
		the local implementation, enable them on the associated payload
		types.

		* For any specified "TIAS" bandwidth value, set this value as the
		maximum RTP bitrate to be used when sending media. If a "TIAS"
		value is not present, but an "AS" value is, generate a TIAS a
		value using this formula: [TODO: convert AS to TIAS].

		* [TODO: handling of CN, telephone-event, "red"]

		* If the media section if of type audio:

		+ For any specified "ptime" value, configure the available
		payload types to use the specified packet size. If the
		specified size is not supported for a payload type, use the
		next closest value instead.

		Finally, if this description is of type "pranswer" or "answer",
		follow the processing defined in the Section 5.9 section below.

	5.9. Applying an Answer	5.9. Applying an Answer


	TODO	In addition to the steps mentioned above for processing a local or
		remote description, the following steps are performed when processing
		a description of type "pranswer" or "answer".

		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
		in the answer), stop any reception or transmission of media for
		this section, and discard any associated ICE components. [TODO:
		ref]

		o If the remote DTLS fingerprint has been changed, tear down the
		existing DTLS connection.

		o If no valid DTLS connection exists, prepare to start a DTLS
		connection, using the specified roles and fingerprints, on any
		underlying ICE components, once they are active.

		o If the media section proto value indicates use of RTP:

		* If the media section has RTCP mux enabled, discard any RTCP
		component, and begin or continue muxing RTCP over the RTP
		component, as specified in [RFC5761], Section 5.1.3.
		Otherwise, transmit RTCP over the RTCP component; if no RTCP
		component exists, because RTCP mux was previously enabled, this
		MUST result in an error.

		* If the media section has reduced-size RTCP enabled, configure
		the RTCP transmission for this media section to use reduced-
		size RTCP, as specified in [TODO: ref]

		* If the directional attribute in the answer is of type
		"sendrecv" or "sendonly", prepare to start transmitting media
		using the specified primary SSRC and one of the selected
		payload types, once the underlying transport layers have been
		established. Otherwise, stop transmitting RTP media, although
		RTCP should still be sent. [TODO: ref]

		o If the media section proto value indicates use of SCTP:

		* If no SCTP association yet exists, prepare to initiate a SCTP
		association over the associated ICE component and DTLS
		connection, using the local SCTP port value from the local
		description, and the remote SCTP port value from the remote
		description. [TODO: ref]

		If the answer contains valid BUNDLE groups, discard any ICE
		components for the m= sections that will be bundled onto the primary
		ICE components in each BUNDLE, and begin muxing these m= sections
		accordingly. [TODO: ref]

		If the answer contains any "a=ice-options" attributes where "trickle"
		is listed as an attribute, update the PeerConnection canTrickle
		property to be true. Otherwise, set this property to false.

	6. Configurable SDP Parameters	6. Configurable SDP Parameters

	It is possible to change elements in the SDP returned from	It is possible to change elements in the SDP returned from
	createOffer before passing it to setLocalDescription. When an	createOffer before passing it to setLocalDescription. When an
	implementation receives modified SDP it MUST either:	implementation receives modified SDP it MUST either:

	o Accept the changes and adjust its behavior to match the SDP.	o Accept the changes and adjust its behavior to match the SDP.

	o Reject the changes and return an error via the error callback.	o Reject the changes and return an error via the error callback.

	skipping to change at page 51, line 19	skipping to change at page 54, line 48
	browser MUST NOT honor an attempt to change them:	browser MUST NOT honor an attempt to change them:

	o The number, type and port number of m= lines.	o The number, type and port number of m= lines.

	o The generated ICE credentials (a=ice-ufrag and a=ice-pwd).	o The generated ICE credentials (a=ice-ufrag and a=ice-pwd).

	o The set of ICE candidates and their parameters (a=candidate).	o The set of ICE candidates and their parameters (a=candidate).

	o The DTLS fingerprint(s) (a=fingerprint).	o The DTLS fingerprint(s) (a=fingerprint).


		o The contents of BUNDLE groups, bundle-only parameters, or "a=rtcp-
		mux" parameters.

	The following modifications, if done by the browser to a description	The following modifications, if done by the browser to a description
	between createOffer/createAnswer and the setLocalDescription, MUST be	between createOffer/createAnswer and the setLocalDescription, MUST be
	honored by the browser:	honored by the browser:

	o Remove or reorder codecs (m=)	o Remove or reorder codecs (m=)

	The following parameters may be controlled by options passed into	The following parameters may be controlled by options passed into
	createOffer/createAnswer. As an open issue, these changes may also	createOffer/createAnswer. As an open issue, these changes may also
	be be performed by manipulating the SDP returned from createOffer/	be be performed by manipulating the SDP returned from createOffer/
	createAnswer, as indicated above, as long as the capabilities of the	createAnswer, as indicated above, as long as the capabilities of the

	skipping to change at page 59, line 12	skipping to change at page 63, line 12

	The SDP for \|offer-B1\| looks like:	The SDP for \|offer-B1\| looks like:

	v=0	v=0
	o=- 4962303333179871723 1 IN IP4 0.0.0.0	o=- 4962303333179871723 1 IN IP4 0.0.0.0
	s=-	s=-
	t=0 0	t=0 0
	a=msid-semantic:WMS	a=msid-semantic:WMS
	a=group:BUNDLE a1 d1	a=group:BUNDLE a1 d1
	m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98	m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98

	c=IN IP6 ::	c=IN IP4 0.0.0.0
	a=rtcp:9 IN IP6 ::	a=rtcp:9 IN IP4 0.0.0.0
	a=mid:a1	a=mid:a1
	a=msid:57017fee-b6c1-4162-929c-a25110252400	a=msid:57017fee-b6c1-4162-929c-a25110252400
	e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9	e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
	a=sendrecv	a=sendrecv
	a=rtpmap:96 opus/48000/2	a=rtpmap:96 opus/48000/2
	a=rtpmap:0 PCMU/8000	a=rtpmap:0 PCMU/8000
	a=rtpmap:8 PCMA/8000	a=rtpmap:8 PCMA/8000
	a=rtpmap:97 telephone-event/8000	a=rtpmap:97 telephone-event/8000
	a=rtpmap:98 telephone-event/48000	a=rtpmap:98 telephone-event/48000
	a=maxptime:120	a=maxptime:120

	skipping to change at page 59, line 38	skipping to change at page 63, line 38
	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	a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7

	m=application 9 UDP/DTLS/SCTP webrtc-datachannel	m=application 9 UDP/DTLS/SCTP webrtc-datachannel

	c=IN IP6 ::	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=ice-ufrag:ATEn1v9DoTMB9J4r	a=ice-ufrag:ATEn1v9DoTMB9J4r
	a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl	a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
	a=ice-options:trickle	a=ice-options:trickle
	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 61, line 12	skipping to change at page 65, line 12

	The SDP for \|answer-B1\| looks like:	The SDP for \|answer-B1\| looks like:

	v=0	v=0
	o=- 7729291447651054566 1 IN IP4 0.0.0.0	o=- 7729291447651054566 1 IN IP4 0.0.0.0
	s=-	s=-
	t=0 0	t=0 0
	a=msid-semantic:WMS	a=msid-semantic:WMS
	a=group:BUNDLE a1 d1	a=group:BUNDLE a1 d1
	m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98	m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98

	c=IN IP6 ::	c=IN IP4 0.0.0.0
	a=rtcp:9 IN IP6 ::	a=rtcp:9 IN IP4 0.0.0.0
	a=mid:a1	a=mid:a1
	a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1	a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
	QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0	QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0
	a=sendrecv	a=sendrecv
	a=rtpmap:96 opus/48000/2	a=rtpmap:96 opus/48000/2
	a=rtpmap:0 PCMU/8000	a=rtpmap:0 PCMU/8000
	a=rtpmap:8 PCMA/8000	a=rtpmap:8 PCMA/8000
	a=rtpmap:97 telephone-event/8000	a=rtpmap:97 telephone-event/8000
	a=rtpmap:98 telephone-event/48000	a=rtpmap:98 telephone-event/48000
	a=maxptime:120	a=maxptime:120

	skipping to change at page 61, line 37	skipping to change at page 65, line 37
	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	a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5

	m=application 9 UDP/DTLS/SCTP webrtc-datachannel	m=application 9 UDP/DTLS/SCTP webrtc-datachannel

	c=IN IP6 ::	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=ice-ufrag:7sFvz2gdLkEwjZEr	a=ice-ufrag:7sFvz2gdLkEwjZEr
	a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2	a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
	a=ice-options:trickle	a=ice-options:trickle
	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 72, line 16	skipping to change at page 76, line 16
	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. 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-12:

		o Filled in sections on applying local and remote descriptions.

		o Discussed downscaling and upscaling to fulfill imageattr
		requirements.

		o Updated what SDP can be modified by the application.

		o Updated to latest datachannel SDP.

		o Allowed multiple fingerprint lines.

		o Switched back to IPv4 for dummy candidates.

		o Added additional clarity on ICE default candidates.

		Changes in draft-11:

		o Clarified handling of RTP CNAMEs.

		o Updated what SDP lines should be processed or ignored.

		o Specified how a=imageattr should be used.

		Changes in draft-10:

		o TODO

	Changes in draft-09:	Changes in draft-09:

	o Don't return null for {local,remote}Description after close().	o Don't return null for {local,remote}Description after close().

	o Changed TCP/TLS to UDP/DTLS in RTP profile names.	o Changed TCP/TLS to UDP/DTLS in RTP profile names.

	o Separate out bundle and mux policy.	o Separate out bundle and mux policy.

	o Added specific references to FEC mechanisms.	o Added specific references to FEC mechanisms.


End of changes. 40 change blocks.
	88 lines changed or deleted	289 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/