draft-ietf-mmusic-data-channel-sdpneg-23.txt		draft-ietf-mmusic-data-channel-sdpneg-24.txt
	MMUSIC K. Drage		MMUSIC K. Drage
	Internet-Draft Unaffiliated		Internet-Draft Unaffiliated
	Intended status: Standards Track M. Makaraju		Intended status: Standards Track M. Makaraju
	Expires: July 21, 2019 Nokia		Expires: September 5, 2019 Nokia
	J. Stoetzer-Bradler
	R. Ejzak		R. Ejzak
	J. Marcon		J. Marcon
	Unaffiliated		Unaffiliated
	R. Even, Ed.		R. Even, Ed.
	Huawei		Huawei
	January 17, 2019		March 4, 2019
	SDP-based Data Channel Negotiation		SDP-based Data Channel Negotiation
	draft-ietf-mmusic-data-channel-sdpneg-23		draft-ietf-mmusic-data-channel-sdpneg-24
	Abstract		Abstract
	Data channel setup can be done using either the in- band Data Channel		Data channel setup can be done using either the in- band Data Channel
	Establishment Protocol (DCEP) or using some out-of- band non-DCEP		Establishment Protocol (DCEP) or using some out-of- band non-DCEP
	protocol. This document specifies how the SDP (Session Description		protocol. This document specifies how the SDP (Session Description
	Protocol) offer/answer exchange can be used to achieve an out-of-band		Protocol) offer/answer exchange can be used to achieve an out-of-band
	non-DCEP negotiation for establishing a data channel.		non-DCEP negotiation for establishing a data channel.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 40 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 July 21, 2019.		This Internet-Draft will expire on September 5, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 49 ¶		skipping to change at page 2, line 48 ¶
	6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 15		6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 15
	6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 16		6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 16
	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16		7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 19		9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 19
	9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19		9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19
	9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 19		9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 20		9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 20
	9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 20		9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 20
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
	11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 21		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
	11.1. Changes against 'draft-ietf-mmusic-data-channel-		12. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 21
			12.1. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 21		sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 21
	11.2. Changes against 'draft-ietf-mmusic-data-channel-		12.2. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 21		sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 21
	11.3. Changes against 'draft-ietf-mmusic-data-channel-		12.3. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 21		sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 21
	11.4. Changes against 'draft-ietf-mmusic-data-channel-		12.4. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 21		sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 21
	11.5. Changes against 'draft-ietf-mmusic-data-channel-		12.5. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 22		sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 22
	11.6. Changes against 'draft-ietf-mmusic-data-channel-		12.6. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 22		sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 22
	11.7. Changes against 'draft-ietf-mmusic-data-channel-		12.7. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 23		sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 23
	11.8. Changes against 'draft-ietf-mmusic-data-channel-		12.8. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 23		sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 23
	11.9. Changes against 'draft-ietf-mmusic-data-channel-		12.9. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 23		sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 23
	11.10. Changes against 'draft-ietf-mmusic-data-channel-		12.10. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 23		sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 23
	11.11. Changes against 'draft-ietf-mmusic-data-channel-		12.11. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 24		sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 24
	11.12. Changes against 'draft-ietf-mmusic-data-channel-		12.12. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 25		sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 25
	11.13. Changes against 'draft-ietf-mmusic-data-channel-		12.13. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 26		sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 26
	11.14. Changes against 'draft-ietf-mmusic-data-channel-		12.14. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 27		sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 27
	11.15. Changes against 'draft-ietf-mmusic-data-channel-		12.15. Changes against 'draft-ietf-mmusic-data-channel-
	sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 29		sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 29
	11.16. Changes against 'draft-ejzak-mmusic-data-channel-		12.16. Changes against 'draft-ejzak-mmusic-data-channel-
	sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 32		sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 32
	11.17. Changes against '-01' . . . . . . . . . . . . . . . . . 33		12.17. Changes against '-01' . . . . . . . . . . . . . . . . . 33
	11.18. Changes against '-00' . . . . . . . . . . . . . . . . . 33		12.18. Changes against '-00' . . . . . . . . . . . . . . . . . 33
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	12.1. Normative References . . . . . . . . . . . . . . . . . . 34		13.1. Normative References . . . . . . . . . . . . . . . . . . 34
	12.2. Informative References . . . . . . . . . . . . . . . . . 35		13.2. Informative References . . . . . . . . . . . . . . . . . 35
	Appendix A. Generic Data Channel Negotiation Aspects When Not		Appendix A. Generic Data Channel Negotiation Aspects When Not
	Using DCEP . . . . . . . . . . . . . . . . . . . . . 36		Using DCEP . . . . . . . . . . . . . . . . . . . . . 36
	A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 36		A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 37
	A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37		A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37
	A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37		A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37
	A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37		A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37
	A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38		A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	The concept of establishing a bi-directional data channels running on		The concept of establishing a bi-directional data channels running on
	top of the Stream Control Transmission Protocol (SCTP) is in		top of the Stream Control Transmission Protocol (SCTP) is in
	[I-D.ietf-rtcweb-data-channel] allowing applications to use data		[I-D.ietf-rtcweb-data-channel] allowing applications to use data
	channels. An in-band Data Channel Establishment Protocol (DCEP) is		channels. An in-band Data Channel Establishment Protocol (DCEP) is
	in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-		in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-
	band protocols may be used for establishing data channels. Each data		band protocols may be used for establishing data channels. Each data
	channel consists of paired SCTP streams sharing the same SCTP Stream		channel consists of paired SCTP streams sharing the same SCTP Stream
	skipping to change at page 7, line 43 ¶		skipping to change at page 7, line 43 ¶
	quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE		quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE
	quoted-char = SP / quoted-visible		quoted-char = SP / quoted-visible
	quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or %		quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or %
	escaped-char = "%" HEXDIG HEXDIG		escaped-char = "%" HEXDIG HEXDIG
	DQUOTE = <from-RFC5234>		DQUOTE = <from-RFC5234>
	integer = <from-RFC4566>		integer = <from-RFC4566>
	Examples:		Examples:
	a=dcmap:0		a=dcmap:0
	a=dcmap:1 subprotocol="BFCP";max-time=60000;priority=512		a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512
	a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP"		a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"
	a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128		a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128
	a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000		a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000
	Note: The last example (a=dcmap:4) shows a 'label' parameter value		Note: The last example (a=dcmap:4) shows a 'label' parameter value
	which contains one non-printable 'escaped-char' character (the		which contains one non-printable 'escaped-char' character (the
	tabulator character).		tabulator character).
	Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one		Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one
	'maxretr-opt' parameter or one 'maxtime-opt' parameter may be		'maxretr-opt' parameter or one 'maxtime-opt' parameter may be
	present. Both MUST NOT be present.		present. Both MUST NOT be present.
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 33 ¶
	replaced with an attribute of the form "a=dcsa:stream-id original-		replaced with an attribute of the form "a=dcsa:stream-id original-
	attribute", where dcsa stands for "data channel subprotocol		attribute", where dcsa stands for "data channel subprotocol
	attribute", stream-id is the SCTP stream identifier assigned to this		attribute", stream-id is the SCTP stream identifier assigned to this
	subprotocol instance, and original-attribute represents the contents		subprotocol instance, and original-attribute represents the contents
	of the subprotocol related attribute to be included.		of the subprotocol related attribute to be included.
	The same syntax applies to any other SDP attribute required for		The same syntax applies to any other SDP attribute required for
	negotiation of this instance of the subprotocol.		negotiation of this instance of the subprotocol.
	The detailed offer/answer procedures for the dcsa attribute are		The detailed offer/answer procedures for the dcsa attribute are
	dependent on the associated sub-protocol. A sub-protocol		dependent on the associated sub-protocol. If no offer/answer
	specification MUST define the offer/answer procedures for the dsca		procedures exist for the sub-protocol when used outside of the dcsa
	attribute (if applicable) associated with the sub-protocol, if the		attribute, no specification is needed for use with dcsa. The IANA
			registration procedures for the WebSocket Subprotocol Name Registry
			(Section 9.1) do not strictly require a specification of the offer/
			answer procedures for the sub-protocol when used with dcsa. If the
	sub-protocol has defined offer/answer procedures when used outside of		sub-protocol has defined offer/answer procedures when used outside of
	dcsa. If no offer/answer procedures exist for the sub-protocol when		dcsa, such a specification is encouraged to ensure interoperability.
	used outside of the dcsa attribute, no specification is required for		If the sub-protocol has defined offer/answer procedures when used
	use with dcsa.		outside of dcsa, but no specification exists for the offer/answer
			procedures for the sub-protocol when used with dcsa, implementations
			SHOULD assume the use of the default values for all otherwise-
			negotiable and applicable sub-protocol parameters.
	5.2.1. DCSA Syntax		5.2.1. DCSA Syntax
	Formal Syntax:		Formal Syntax:
	Name: dcsa		Name: dcsa
	Value: dcsa-value		Value: dcsa-value
	Usage Level: media		Usage Level: media
	Charset Dependent: no		Charset Dependent: no
	Syntax:		Syntax:
	dcsa-value = stream-id SP attribute		dcsa-value = stream-id SP attribute
	attribute = <from-RFC4566>		attribute = <from-RFC4566>
	Example:		Example:
	a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP"		a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"
	a=dcsa:2 accept-types:text/plain		a=dcsa:2 accept-types:text/plain
	Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where		Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where
	the attribute definition can be found; it does not provide any		the attribute definition can be found; it does not provide any
	limitation on support of attributes defined in other documents in		limitation on support of attributes defined in other documents in
	accordance with this attribute definition. Note however that not all		accordance with this attribute definition. Note however that not all
	SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP		SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP
	parameters contains the lists of IANA (Internet Assigned Numbers		parameters contains the lists of IANA (Internet Assigned Numbers
	Authority) registered session and media level or media level only SDP		Authority) registered session and media level or media level only SDP
	skipping to change at page 12, line 47 ¶		skipping to change at page 12, line 47 ¶
	The generic offer/answer procedures for negotiating the SCTP		The generic offer/answer procedures for negotiating the SCTP
	association used to realize data channels are defined in		association used to realize data channels are defined in
	[I-D.ietf-mmusic-sctp-sdp]. This section only defines the data		[I-D.ietf-mmusic-sctp-sdp]. This section only defines the data
	channel specific procedures.		channel specific procedures.
	"Initial offer" refers to the offer in which a data channel is		"Initial offer" refers to the offer in which a data channel is
	opened. It can be the initial offer, or a subsequent offer, of the		opened. It can be the initial offer, or a subsequent offer, of the
	associated SDP session.		associated SDP session.
	The detailed offer/answer procedures for the dcsa attribute are		The detailed offer/answer procedures for the dcsa attribute are
	dependent on the associated sub-protocol. A sub-protocol		dependent on the associated sub-protocol see Section 5.2.
	specification MUST define the offer/answer procedures for the dsca
	attribute (if applicable) associated with the sub-protocol.
	6.1. Managing Stream Identifiers		6.1. Managing Stream Identifiers
	In order to avoid SCTP Stream identifier collisions, in alignment		In order to avoid SCTP Stream identifier collisions, in alignment
	with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS		with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS
	client (for the SCTP association used to realize data channels) MUST		client (for the SCTP association used to realize data channels) MUST
	use even identifier values, and the endpoint acting as DTLS server		use even identifier values, and the endpoint acting as DTLS server
	MUST use odd identifier values. SCTP stream identifiers associated		MUST use odd identifier values. SCTP stream identifiers associated
	with data channels that have been negotiated using DCEP MUST NOT be		with data channels that have been negotiated using DCEP MUST NOT be
	included in SDP offers and answers.		included in SDP offers and answers.
	skipping to change at page 16, line 39 ¶		skipping to change at page 16, line 39 ¶
	SDP offer:		SDP offer:
	m=application 10001 UDP/DTLS/SCTP webrtc-datachannel		m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP6 IP6 2001:db8::3		c=IN IP6 IP6 2001:db8::3
	a=max-message-size:100000		a=max-message-size:100000
	a=sctp-port:5000		a=sctp-port:5000
	a=setup:actpass		a=setup:actpass
	a=fingerprint:SHA-1 \		a=fingerprint:SHA-1 \
	4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB		4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
	a=tls-id:abc3de65cddef001be82		a=tls-id:abc3de65cddef001be82
	a=dcmap:0 subprotocol="BFCP";label="BFCP"		a=dcmap:0 subprotocol="bfcp";label="bfcp"
	SDP answer:		SDP answer:
	m=application 10002 UDP/DTLS/SCTP webrtc-datachannel		m=application 10002 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP6 IP6 2001:db8::1		c=IN IP6 IP6 2001:db8::1
	a=max-message-size:100000		a=max-message-size:100000
	a=sctp-port:5002		a=sctp-port:5002
	a=setup:passive		a=setup:passive
	a=fingerprint:SHA-1 \		a=fingerprint:SHA-1 \
	5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA		5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
	skipping to change at page 17, line 23 ¶		skipping to change at page 17, line 23 ¶
	SDP offer:		SDP offer:
	m=application 10001 UDP/DTLS/SCTP webrtc-datachannel		m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP4 192.0.2.1		c=IN IP4 192.0.2.1
	a=max-message-size:100000		a=max-message-size:100000
	a=sctp-port:5000		a=sctp-port:5000
	a=setup:actpass		a=setup:actpass
	a=fingerprint:SHA-1 \		a=fingerprint:SHA-1 \
	4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB		4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
	a=tls-id:abc3de65cddef001be82		a=tls-id:abc3de65cddef001be82
	a=dcmap:0 subprotocol="BFCP";label="BFCP"		a=dcmap:0 subprotocol="bfcp";label="bfcp"
	a=dcmap:2 subprotocol="MSRP";label="MSRP"		a=dcmap:2 subprotocol="msrp";label="msrp"
	a=dcsa:2 accept-types:message/cpim text/plain		a=dcsa:2 accept-types:message/cpim text/plain
	a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc		a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc
	SDP answer:		SDP answer:
	m=application 10002 UDP/DTLS/SCTP webrtc-datachannel		m=application 10002 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP4 192.0.2.2		c=IN IP4 192.0.2.2
	a=max-message-size:100000		a=max-message-size:100000
	a=sctp-port:5002		a=sctp-port:5002
	a=setup:passive		a=setup:passive
	a=fingerprint:SHA-1 \		a=fingerprint:SHA-1 \
	5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA		5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
	a=tls-id:dcb3ae65cddef0532d42		a=tls-id:dcb3ae65cddef0532d42
	a=dcmap:2 subprotocol="MSRP";label="MSRP"		a=dcmap:2 subprotocol="msrp";label="msrp"
	a=dcsa:2 accept-types:message/cpim text/plain		a=dcsa:2 accept-types:message/cpim text/plain
	a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc		a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc
	Figure 2: Example 2		Figure 2: Example 2
	In the example in Figure 2 the SDP offer contains data channels for		In the example in Figure 2 the SDP offer contains data channels for
	BFCP (Binary Floor Control Protocol) and MSRP subprotocols. The SDP		BFCP (Binary Floor Control Protocol) and MSRP subprotocols. The SDP
	answer rejected BFCP and accepted MSRP. So, the offerer closes the		answer rejected BFCP and accepted MSRP. So, the offerer closes the
	data channel for BFCP and both offerer and answerer may start using		data channel for BFCP and both offerer and answerer may start using
	the MSRP data channel (after the SCTP association is set up). The		the MSRP data channel (after the SCTP association is set up). The
	skipping to change at page 18, line 15 ¶		skipping to change at page 18, line 15 ¶
	Subsequent SDP offer:		Subsequent SDP offer:
	m=application 10001 UDP/DTLS/SCTP webrtc-datachannel		m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP4 192.0.2.1		c=IN IP4 192.0.2.1
	a=max-message-size:100000		a=max-message-size:100000
	a=sctp-port:5000		a=sctp-port:5000
	a=setup:actpass		a=setup:actpass
	a=fingerprint:SHA-1 \		a=fingerprint:SHA-1 \
	4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB		4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
	a=tls-id:abc3de65cddef001be82		a=tls-id:abc3de65cddef001be82
	a=dcmap:4 subprotocol="MSRP";label="MSRP"		a=dcmap:4 subprotocol="msrp";label="msrp"
	a=dcsa:4 accept-types:message/cpim text/plain		a=dcsa:4 accept-types:message/cpim text/plain
	a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc		a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc
	Subsequent SDP answer:		Subsequent SDP answer:
	m=application 10002 UDP/DTLS/SCTP webrtc-datachannel		m=application 10002 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP4 192.0.2.2		c=IN IP4 192.0.2.2
	a=max-message-size:100000		a=max-message-size:100000
	a=sctp-port:5002		a=sctp-port:5002
	a=setup:passive		a=setup:passive
	a=fingerprint:SHA-1 \		a=fingerprint:SHA-1 \
	5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA		5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
	a=tls-id:dcb3ae65cddef0532d42		a=tls-id:dcb3ae65cddef0532d42
	a=dcmap:4 subprotocol="MSRP";label="MSRP"		a=dcmap:4 subprotocol="msrp";label="msrp"
	a=dcsa:4 accept-types:message/cpim text/plain		a=dcsa:4 accept-types:message/cpim text/plain
	a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc		a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc
	Figure 3: Example 3		Figure 3: Example 3
	The example in Figure 3 is a continuation of the example in Figure 2.		The example in Figure 3 is a continuation of the example in Figure 2.
	The SDP offerer now removes the MSRP data channel with stream id 2,		The SDP offerer now removes the MSRP data channel with stream id 2,
	but opens a new MSRP data channel with stream id 4. The answerer		but opens a new MSRP data channel with stream id 4. The answerer
	accepts the entire offer. As a result the offerer closes the earlier		accepts the entire offer. As a result the offerer closes the earlier
	negotiated MSRP related data channel and both offerer and answerer		negotiated MSRP related data channel and both offerer and answerer
	skipping to change at page 21, line 10 ¶		skipping to change at page 21, line 10 ¶
	dcsa usage level, SHALL use the dcsa usage level when registering the		dcsa usage level, SHALL use the dcsa usage level when registering the
	attribute. If existing media attributes are used in a datachannel		attribute. If existing media attributes are used in a datachannel
	subprotocol specific way (Section 5.2.1), then a new dcsa usage level		subprotocol specific way (Section 5.2.1), then a new dcsa usage level
	MUST be defined for the existing media attribute. Where the SDP		MUST be defined for the existing media attribute. Where the SDP
	attribute is applicable to a particular subprotocol/s this SHALL also		attribute is applicable to a particular subprotocol/s this SHALL also
	be registered by indicating the applicable subprotocol identifiers		be registered by indicating the applicable subprotocol identifiers
	(see Section 9.1) along with the dcsa usage level. E.g.		(see Section 9.1) along with the dcsa usage level. E.g.
	+-----------------------+-------------------------------------------+		+-----------------------+-------------------------------------------+
	| ... | ... |		| ... | ... |
	| Usage level: | dcsa(MSRP) |		| Usage level: | dcsa(msrp) |
	| ... | ... |		| ... | ... |
	+-----------------------+-------------------------------------------+		+-----------------------+-------------------------------------------+
	10. Acknowledgments		10. Contributors
			Juergen Stoetzer-Bradler co-authored this document.
			11. Acknowledgments
	The authors wish to acknowledge the borrowing of ideas from other		The authors wish to acknowledge the borrowing of ideas from other
	internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley		internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley
	and Gavin Llewellyn, and to thank Flemming Andreasen, Christian		and Gavin Llewellyn, and to thank Flemming Andreasen, Christian
	Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe		Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe
	Rauschenbach and Roman Shpount for their invaluable comments.		Rauschenbach and Roman Shpount for their invaluable comments.
	Special thanks to Christer Holmberg for helping finish the document		Special thanks to Christer Holmberg for helping finish the document
	and cleaning the SDP offer/answer section.		and cleaning the SDP offer/answer section.
	11. CHANGE LOG		12. CHANGE LOG
	11.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15'		12.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15'
	o Editorial changes separate sections for offer/answer procedures.		o Editorial changes separate sections for offer/answer procedures.
	o Update security section.		o Update security section.
	11.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14'		12.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14'
	o Change "dtls-id" to "tls-id" and assign 20 octet long values		o Change "dtls-id" to "tls-id" and assign 20 octet long values
	o Remove of RFC4566bis draft from list of normative references.		o Remove of RFC4566bis draft from list of normative references.
	11.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12'		12.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12'
	o Modification of Keith's address information.		o Modification of Keith's address information.
	11.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11'		12.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11'
	o dcmap-stream-id syntax change to limit size to 5 digits.		o dcmap-stream-id syntax change to limit size to 5 digits.
	o Add missing 'x' prefix to quoted-visible syntax.		o Add missing 'x' prefix to quoted-visible syntax.
	o Align SDP offerer and answerer handling when both max-retr and		o Align SDP offerer and answerer handling when both max-retr and
	max-time are present.		max-time are present.
	o Use of TEST-NET-1 ip addresses in examples.		o Use of TEST-NET-1 ip addresses in examples.
	o Add missing a=dtls-id in one example.		o Add missing a=dtls-id in one example.
	11.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10'		12.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10'
	o Removal of the "a=connection" attribute lines from all SDP		o Removal of the "a=connection" attribute lines from all SDP
	examples.		examples.
	11.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09'		12.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09'
	o In the introduction:		o In the introduction:
	* Replacement of the sentence "The RTCWeb working group has		* Replacement of the sentence "The RTCWeb working group has
	defined the concept of bi-directional data channels running on		defined the concept of bi-directional data channels running on
	top of SCTP/DTLS (SCTP over the Datagram Transport Layer		top of SCTP/DTLS (SCTP over the Datagram Transport Layer
	Security protocol)" with "The RTCWeb working group has defined		Security protocol)" with "The RTCWeb working group has defined
	the concept of bi-directional data channels running on top of		the concept of bi-directional data channels running on top of
	the Stream Control Transmission Protocol (SCTP)".		the Stream Control Transmission Protocol (SCTP)".
	skipping to change at page 23, line 8 ¶		skipping to change at page 23, line 11 ¶
	o In the text after the second SDP answer in section Section 7		o In the text after the second SDP answer in section Section 7
	replacement of "... (after SCTP/DTLS association is setup)" with		replacement of "... (after SCTP/DTLS association is setup)" with
	"... (after the SCTP association is set up)".		"... (after the SCTP association is set up)".
	o Addition of draft-ietf-mmusic-dtls-sdp to the list of informative		o Addition of draft-ietf-mmusic-dtls-sdp to the list of informative
	references.		references.
	o Addition of "a=dtls-id" attribute lines to the SDP offer/answer		o Addition of "a=dtls-id" attribute lines to the SDP offer/answer
	examples in Section 7.		examples in Section 7.
	11.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08'		12.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08'
	o Addition of definition of "data channel subprotocol" to Section 3		o Addition of definition of "data channel subprotocol" to Section 3
	as proposed on the MMUSIC list, https://www.ietf.org/mail-		as proposed on the MMUSIC list, https://www.ietf.org/mail-
	archive/web/mmusic/current/msg15827.html.		archive/web/mmusic/current/msg15827.html.
	o Addition of RFC4566bis draft to list of normative references.		o Addition of RFC4566bis draft to list of normative references.
	o Updates of tables in Section 9.2.1 and Section 9.2.2 as per		o Updates of tables in Section 9.2.1 and Section 9.2.2 as per
	section 8.2.4 of RFC4566bis draft.		section 8.2.4 of RFC4566bis draft.
	o Addition of new Section 9.3.		o Addition of new Section 9.3.
	11.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07'		12.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07'
	o Addition of two new paragraphs to Section 5.2.1 regarding		o Addition of two new paragraphs to Section 5.2.1 regarding
	subprotocol attribute relationship with transport protocol.		subprotocol attribute relationship with transport protocol.
	o Addition of a note to Section 9.1 regarding subprotocols		o Addition of a note to Section 9.1 regarding subprotocols
	simultaneously defined for data channel and Websocket usage.		simultaneously defined for data channel and Websocket usage.
	o Addition of two further SDP offer/answer considerations to		o Addition of two further SDP offer/answer considerations to
	Section 6.7 regarding unknown subprotocol attributes and known		Section 6.7 regarding unknown subprotocol attributes and known
	subprotocol attributes with unknown data channel transport related		subprotocol attributes with unknown data channel transport related
	semantic.		semantic.
	11.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06'		12.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06'
	o Changes addressing Christian Groves's WGLC review comments raised		o Changes addressing Christian Groves's WGLC review comments raised
	in http://www.ietf.org/mail-archive/web/mmusic/current/		in http://www.ietf.org/mail-archive/web/mmusic/current/
	msg15357.html and http://www.ietf.org/mail-		msg15357.html and http://www.ietf.org/mail-
	archive/web/mmusic/current/msg15359.html.		archive/web/mmusic/current/msg15359.html.
	11.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05'		12.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05'
	o In IANA registration Section 9.2.1 and Section 9.2.2 replacement		o In IANA registration Section 9.2.1 and Section 9.2.2 replacement
	of contact name and e-mail address with "MMUSIC Chairs" and		of contact name and e-mail address with "MMUSIC Chairs" and
	"mmusic-chairs@ietf.org".		"mmusic-chairs@ietf.org".
	o In Section 5.2.1 replacement of "Thus in the example above, the		o In Section 5.2.1 replacement of "Thus in the example above, the
	original attribute line "a=accept- types:text/plain" is		original attribute line "a=accept- types:text/plain" is
	represented by the attribute line "a=dcsa:2 accept-types:text/		represented by the attribute line "a=dcsa:2 accept-types:text/
	plain", which specifies that this instance of MSRP being		plain", which specifies that this instance of MSRP being
	transported on the SCTP association using the data channel with		transported on the SCTP association using the data channel with
	skipping to change at page 24, line 30 ¶		skipping to change at page 24, line 32 ¶
	o Move of the last but one paragraph of Section 5.2.1 starting with		o Move of the last but one paragraph of Section 5.2.1 starting with
	"The same syntax applies to ..." right in front of the formal		"The same syntax applies to ..." right in front of the formal
	syntax definition of the "dcsa" attribute.		syntax definition of the "dcsa" attribute.
	o Modifications of the text in Section 5.1.9 and Section 5.2.2 in		o Modifications of the text in Section 5.1.9 and Section 5.2.2 in
	order not to explicitly restrict usage of the "a=dcmap:" and		order not to explicitly restrict usage of the "a=dcmap:" and
	"a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/		"a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/
	SCTP" or "TCP/DTLS/SCTP".		SCTP" or "TCP/DTLS/SCTP".
	11.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04'		12.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04'
	o In Section 5.1.4 the first (and only) paragraph was "The		o In Section 5.1.4 the first (and only) paragraph was "The
	'subprotocol' parameter indicates which protocol the client		'subprotocol' parameter indicates which protocol the client
	expects to exchange via the channel. 'Subprotocol' is an optional		expects to exchange via the channel. 'Subprotocol' is an optional
	parameter. If the 'subprotocol' parameter is not present, then		parameter. If the 'subprotocol' parameter is not present, then
	its value defaults to the empty string." Replacement of this		its value defaults to the empty string." Replacement of this
	paragraph with following two paragraphs:		paragraph with following two paragraphs:
	* The 'subprotocol' parameter indicates which protocol the client		* The 'subprotocol' parameter indicates which protocol the client
	expects to exchange via the channel. This parameter maps to		expects to exchange via the channel. This parameter maps to
	skipping to change at page 25, line 23 ¶		skipping to change at page 25, line 26 ¶
	o Addition of new Section 5.1.9 describing the mux category of the		o Addition of new Section 5.1.9 describing the mux category of the
	dcmap SDP attribute. This section and the new "a=dcsa:" attribute		dcmap SDP attribute. This section and the new "a=dcsa:" attribute
	related mux category section are similar to the "Mux Category"		related mux category section are similar to the "Mux Category"
	sections of the "a=sctp-port:" and "a=max-message-size:"		sections of the "a=sctp-port:" and "a=max-message-size:"
	attributes in [I-D.ietf-mmusic-sctp-sdp].		attributes in [I-D.ietf-mmusic-sctp-sdp].
	o Addition of new Section 5.2.2 describing the mux category of the		o Addition of new Section 5.2.2 describing the mux category of the
	dcsa SDP attribute.		dcsa SDP attribute.
	11.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03'		12.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03'
	o In Section 1 replacement of "RTCWeb leaves it open for other		o In Section 1 replacement of "RTCWeb leaves it open for other
	applications to use data channels and its in-band DCEP or out-of-		applications to use data channels and its in-band DCEP or out-of-
	band non-DCEP protocols for creating them" with "... to use data		band non-DCEP protocols for creating them" with "... to use data
	channels and its in-band DCEP or other in-band or out-of-band		channels and its in-band DCEP or other in-band or out-of-band
	protocols for creating them". Additionally replacement of "In		protocols for creating them". Additionally replacement of "In
	particular, the SDP offer generated by the application includes no		particular, the SDP offer generated by the application includes no
	channel-specific information" with "... generated by the RTCweb		channel-specific information" with "... generated by the RTCweb
	data channel stack includes no channel-specific information".		data channel stack includes no channel-specific information".
	skipping to change at page 26, line 33 ¶		skipping to change at page 26, line 36 ¶
	o In Section 6.1 replacement of "However, an SDP offer/answer		o In Section 6.1 replacement of "However, an SDP offer/answer
	exchange MUST NOT be initiated if the associated SCTP stream is		exchange MUST NOT be initiated if the associated SCTP stream is
	already negotiated via DCEP" with "However, an SCTP stream MUST		already negotiated via DCEP" with "However, an SCTP stream MUST
	NOT be referenced in a dcmap or dcsa attribute of an SDP offer/		NOT be referenced in a dcmap or dcsa attribute of an SDP offer/
	answer exchange if the associated SCTP stream has already been		answer exchange if the associated SCTP stream has already been
	negotiated via DCEP".		negotiated via DCEP".
	o In the examples in Section 7 addition of the previously missing		o In the examples in Section 7 addition of the previously missing
	colons to the "a=sctp-port" attribute lines.		colons to the "a=sctp-port" attribute lines.
	11.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02'		12.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02'
	o Move of reference draft-ietf-rtcweb-jsep from the list of		o Move of reference draft-ietf-rtcweb-jsep from the list of
	normative references to the list of informative references.		normative references to the list of informative references.
	Remover in -07 since not referenced		Remover in -07 since not referenced
	o Addition of IANA SDP parameters to the list of informative		o Addition of IANA SDP parameters to the list of informative
	references and addition of following two sentences to the first		references and addition of following two sentences to the first
	paragraph after the ABNF definition: "Note however that not all		paragraph after the ABNF definition: "Note however that not all
	SDP attributes are suitable as "a=dcsa:" parameter. IANA SDP		SDP attributes are suitable as "a=dcsa:" parameter. IANA SDP
	parameters contains the lists of IANA registered session and media		parameters contains the lists of IANA registered session and media
	skipping to change at page 27, line 34 ¶		skipping to change at page 27, line 36 ¶
	mutually exclusive, so aBoth MUST NOT be present in a=dcmap".		mutually exclusive, so aBoth MUST NOT be present in a=dcmap".
	o Move of reference [WebRtcAPI] from list of normative references to		o Move of reference [WebRtcAPI] from list of normative references to
	list of informative references.		list of informative references.
	o Removal of almost all text parts, which discussed JavaScript or		o Removal of almost all text parts, which discussed JavaScript or
	other API specific aspects. Such API specific aspects were mainly		other API specific aspects. Such API specific aspects were mainly
	discussed in sub-sections of Section 5 and Section 5 of draft-		discussed in sub-sections of Section 5 and Section 5 of draft-
	ietf-mmusic-data-channel-sdpneg-02.		ietf-mmusic-data-channel-sdpneg-02.
	11.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01'		12.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01'
	o New Section 4 regarding applicability to SDP offer/answer only.		o New Section 4 regarding applicability to SDP offer/answer only.
	o Addition of new Section 9.1 "Subprotocol identifiers" as		o Addition of new Section 9.1 "Subprotocol identifiers" as
	subsection of the "IANA Considerations" related Section 9. Also		subsection of the "IANA Considerations" related Section 9. Also
	removal of the temporary note "To be completed. As [I-D.ietf-		removal of the temporary note "To be completed. As [I-D.ietf-
	rtcweb-data-protocol] this document should refer to IANA's		rtcweb-data-protocol] this document should refer to IANA's
	WebSocket Subprotocol Name Registry defined in [RFC6455]"		WebSocket Subprotocol Name Registry defined in [RFC6455]"
	o In Section 6.2:		o In Section 6.2:
	skipping to change at page 29, line 39 ¶		skipping to change at page 29, line 42 ¶
	* In the last but one paragraph replacement of "must" with "The		* In the last but one paragraph replacement of "must" with "The
	application MUST also close...".		application MUST also close...".
	o In Section 5.2 addition of following note after the formal		o In Section 5.2 addition of following note after the formal
	definition of the 'a=dcsa' attribute: "Note that the above		definition of the 'a=dcsa' attribute: "Note that the above
	reference to RFC 4566 defines were the attribute definition can be		reference to RFC 4566 defines were the attribute definition can be
	found; it does not provide any limitation on support of attributes		found; it does not provide any limitation on support of attributes
	defined in other documents in accordance with this attribute		defined in other documents in accordance with this attribute
	definition."		definition."
	11.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00'		12.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00'
	o In Section 3 "WebRTC data channel" was defined as "A bidirectional		o In Section 3 "WebRTC data channel" was defined as "A bidirectional
	channel consisting of paired SCTP outbound and inbound streams."		channel consisting of paired SCTP outbound and inbound streams."
	Replacement of this definition with "Data channel: A WebRTC data		Replacement of this definition with "Data channel: A WebRTC data
	channel as specified in [I-D.ietf-rtcweb-data-channel]", and		channel as specified in [I-D.ietf-rtcweb-data-channel]", and
	consistent usage of "data channel" in the remainder of the		consistent usage of "data channel" in the remainder of the
	document including the document's headline."		document including the document's headline."
	o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in		o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in
	[I-D.ietf-mmusic-sctp-sdp] may change as that document progresses.		[I-D.ietf-mmusic-sctp-sdp] may change as that document progresses.
	skipping to change at page 29, line 50 ¶		skipping to change at page 30, line 4 ¶
	o In Section 3 "WebRTC data channel" was defined as "A bidirectional		o In Section 3 "WebRTC data channel" was defined as "A bidirectional
	channel consisting of paired SCTP outbound and inbound streams."		channel consisting of paired SCTP outbound and inbound streams."
	Replacement of this definition with "Data channel: A WebRTC data		Replacement of this definition with "Data channel: A WebRTC data
	channel as specified in [I-D.ietf-rtcweb-data-channel]", and		channel as specified in [I-D.ietf-rtcweb-data-channel]", and
	consistent usage of "data channel" in the remainder of the		consistent usage of "data channel" in the remainder of the
	document including the document's headline."		document including the document's headline."
	o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in		o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in
	[I-D.ietf-mmusic-sctp-sdp] may change as that document progresses.		[I-D.ietf-mmusic-sctp-sdp] may change as that document progresses.
	In particular we expect "webrtc-datachannel" to become a more		In particular we expect "webrtc-datachannel" to become a more
	general term.'		general term.'
	o Consistent usage of '"m" line' in whole document as per RFC4566.		o Consistent usage of '"m" line' in whole document as per RFC4566.
	o In Section 5.1 removal of the example dcmap attribute line		o In Section 5.1 removal of the example dcmap attribute line
	'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are		'a=dcmap:2 subprotocol="bfcp";label="channel 2' as there are
	already four examples right after the ABNF rules in Section 5.1.1.		already four examples right after the ABNF rules in Section 5.1.1.
	Corresponding removal of following related note: "Note: This		Corresponding removal of following related note: "Note: This
	document does not provide a complete specification of how to		document does not provide a complete specification of how to
	negotiate the use of a WebRTC data channel to transport BFCP.		negotiate the use of a WebRTC data channel to transport BFCP.
	Procedures specific to each subprotocol such as BFCP will be		Procedures specific to each subprotocol such as BFCP will be
	documented elsewhere. The use of BFCP is only an example of how		documented elsewhere. The use of BFCP is only an example of how
	the generic procedures described herein might apply to a specific		the generic procedures described herein might apply to a specific
	subprotocol."		subprotocol."
	o In Section 5.1 removal of following note: "Note: This attribute is		o In Section 5.1 removal of following note: "Note: This attribute is
	skipping to change at page 32, line 23 ¶		skipping to change at page 32, line 26 ¶
	to handle cases where a successful SDP answer is not received, in		to handle cases where a successful SDP answer is not received, in
	which case the state of the session SHOULD be kept per the last		which case the state of the session SHOULD be kept per the last
	successful SDP offer/answer."		successful SDP offer/answer."
	o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects		o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects
	Section 5.1 contained already procedural descriptions related to		Section 5.1 contained already procedural descriptions related to
	data channel reliability negotiation. Creation of new Section 6.2		data channel reliability negotiation. Creation of new Section 6.2
	and moval of reliability negotiation related text to this new		and moval of reliability negotiation related text to this new
	section.		section.
	11.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02'		12.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02'
	o Removal of note "ACTION ITEM" from section "subprotocol		o Removal of note "ACTION ITEM" from section "subprotocol
	parameter". As [I-D.ietf-rtcweb-data-protocol] this document		parameter". As [I-D.ietf-rtcweb-data-protocol] this document
	should refer to IANA's WebSocket Subprotocol Name Registry defined		should refer to IANA's WebSocket Subprotocol Name Registry defined
	in [RFC6455]		in [RFC6455]
	o In whole document, replacement of "unreliable" with "partially		o In whole document, replacement of "unreliable" with "partially
	reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in		reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in
	[I-D.ietf-rtcweb-data-protocol] in most places.		[I-D.ietf-rtcweb-data-protocol] in most places.
	skipping to change at page 33, line 18 ¶		skipping to change at page 33, line 21 ¶
	being present at all. [I-D.ietf-rtcweb-data-protocol] allows the		being present at all. [I-D.ietf-rtcweb-data-protocol] allows the
	DATA_CHANNEL_OPEN message's 'Label' value to be an empty string."		DATA_CHANNEL_OPEN message's 'Label' value to be an empty string."
	o In section "subprotocol parameter" the sentence "Subprotocol is a		o In section "subprotocol parameter" the sentence "Subprotocol is a
	mandatory parameter." was replaced with "'Subprotocol' is an		mandatory parameter." was replaced with "'Subprotocol' is an
	optional parameter. If the 'subprotocol' parameter is not		optional parameter. If the 'subprotocol' parameter is not
	present, then its value defaults to the empty string."		present, then its value defaults to the empty string."
	o In the "Examples" section, in the first two SDP offer examples in		o In the "Examples" section, in the first two SDP offer examples in
	the "a=dcmap" attribute lines 'label="BGCP"' was replaced with		the "a=dcmap" attribute lines 'label="BGCP"' was replaced with
	'label="BFCP"'.		'label="bfcp"'.
	o In all examples, the "m" line proto value "DTLS/SCTP" was replaced		o In all examples, the "m" line proto value "DTLS/SCTP" was replaced
	with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were		with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were
	replaced with "a=max-message-size" attribute lines, as per draft-		replaced with "a=max-message-size" attribute lines, as per draft-
	ietf-mmusic-sctp-sdp-12.		ietf-mmusic-sctp-sdp-12.
	11.17. Changes against '-01'		12.17. Changes against '-01'
	o Formal syntax for dcmap and dcsa attribute lines.		o Formal syntax for dcmap and dcsa attribute lines.
	o Making subprotocol as an optional parameter in dcmap.		o Making subprotocol as an optional parameter in dcmap.
	o Specifying disallowed parameter combinations for max-time and max-		o Specifying disallowed parameter combinations for max-time and max-
	retr.		retr.
	o Clarifications on WebRTC data channel close procedures.		o Clarifications on WebRTC data channel close procedures.
	11.18. Changes against '-00'		12.18. Changes against '-00'
	o Revisions to identify difference between internal and external		o Revisions to identify difference between internal and external
	negotiation and their usage.		negotiation and their usage.
	o Introduction of more generic terminology, e.g. "application"		o Introduction of more generic terminology, e.g. "application"
	instead of "browser".		instead of "browser".
	o Clarification of how "max-retr and max-time affect the usage of		o Clarification of how "max-retr and max-time affect the usage of
	unreliable and reliable WebRTC data channels.		unreliable and reliable WebRTC data channels.
	o Updates of examples to take into account the SDP syntax changes		o Updates of examples to take into account the SDP syntax changes
	introduced with draft-ietf-mmusic-sctp-sdp-07.		introduced with draft-ietf-mmusic-sctp-sdp-07.
	o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa"		o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa"
	attributes as this is now contained in the a=sctp-port attribute,		attributes as this is now contained in the a=sctp-port attribute,
	and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP		and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP
	association on top of the DTLS connection.		association on top of the DTLS connection.
	12. References		13. References
	12.1. Normative References		13.1. Normative References
	[I-D.ietf-mmusic-rfc4566bis]		[I-D.ietf-mmusic-rfc4566bis]
	Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:		Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
	Session Description Protocol", draft-ietf-mmusic-		Session Description Protocol", draft-ietf-mmusic-
	rfc4566bis-32 (work in progress), December 2018.		rfc4566bis-32 (work in progress), December 2018.
	[I-D.ietf-mmusic-sctp-sdp]		[I-D.ietf-mmusic-sctp-sdp]
	Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,		Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,
	"Session Description Protocol (SDP) Offer/Answer		"Session Description Protocol (SDP) Offer/Answer
	Procedures For Stream Control Transmission Protocol (SCTP)		Procedures For Stream Control Transmission Protocol (SCTP)
	skipping to change at page 35, line 19 ¶		skipping to change at page 35, line 23 ¶
	[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control		[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
	Transmission Protocol (SCTP) Stream Reconfiguration",		Transmission Protocol (SCTP) Stream Reconfiguration",
	RFC 6525, DOI 10.17487/RFC6525, February 2012,		RFC 6525, DOI 10.17487/RFC6525, February 2012,
	<https://www.rfc-editor.org/info/rfc6525>.		<https://www.rfc-editor.org/info/rfc6525>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	12.2. Informative References		13.2. Informative References
	[I-D.ietf-clue-datachannel]		[I-D.ietf-clue-datachannel]
	Holmberg, C., "CLUE Protocol data channel", draft-ietf-		Holmberg, C., "CLUE Protocol data channel", draft-ietf-
	clue-datachannel-15 (work in progress), August 2018.		clue-datachannel-15 (work in progress), August 2018.
	[I-D.ietf-mmusic-msrp-usage-data-channel]		[I-D.ietf-mmusic-msrp-usage-data-channel]
	Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R.,		Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R.,
	Marcon, J., and J. Recio, "MSRP over Data Channels",		Marcon, J., and J. Recio, "MSRP over Data Channels",
	draft-ietf-mmusic-msrp-usage-data-channel-09 (work in		draft-ietf-mmusic-msrp-usage-data-channel-09 (work in
	progress), May 2018.		progress), May 2018.
	skipping to change at page 39, line 4 ¶		skipping to change at page 39, line 11 ¶
	Depending upon the method used for DCEP-less negotiation and the		Depending upon the method used for DCEP-less negotiation and the
	subprotocol associated with the data channel, the closing might in		subprotocol associated with the data channel, the closing might in
	addition be signaled to the peer via SDP offer/answer negotiation.		addition be signaled to the peer via SDP offer/answer negotiation.
	Authors' Addresses		Authors' Addresses
	Keith Drage		Keith Drage
	Unaffiliated		Unaffiliated
	Email: drageke@ntlworld.com		Email: drageke@ntlworld.com
	Maridi R. Makaraju (Raju)		Maridi R. Makaraju (Raju)
	Nokia		Nokia
	2000 Lucent Lane		2000 Lucent Lane
	Naperville, Illinois		Naperville, Illinois
	US		US
	Email: Raju.Makaraju@nokia.com		Email: Raju.Makaraju@nokia.com
	Juergen Stoetzer-Bradler
	Unaffiliated
	Email: Juergen.S-B.ietf@email.de
	Richard Ejzak		Richard Ejzak
	Unaffiliated		Unaffiliated
	Email: richard.ejzak@gmail.com		Email: richard.ejzak@gmail.com
	Jerome Marcon		Jerome Marcon
	Unaffiliated		Unaffiliated
	Email: jeromee.marcon@free.fr		Email: jeromee.marcon@free.fr
End of changes. 62 change blocks.
	79 lines changed or deleted		84 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/