< draft-ietf-bfcpbis-bfcp-websocket-06.txt		draft-ietf-bfcpbis-bfcp-websocket-07.txt >
	BFCPBIS Working Group V. Pascual		BFCPBIS Working Group V. Pascual
	Internet-Draft Oracle		Internet-Draft Oracle
	Updates: rfc4582bis, rfc4583bis (if A. Roman		Updates: rfc4582bis, rfc4583bis (if A. Roman
	approved) Quobis		approved) Quobis
	Intended status: Standards Track S. Cazeaux		Intended status: Standards Track S. Cazeaux
	Expires: August 6, 2016 France Telecom Orange		Expires: November 3, 2016 France Telecom Orange
	G. Salgueiro		G. Salgueiro
	R. Ravindranath		R. Ravindranath
	Cisco		Cisco
	S. Garcia Murillo		S. Garcia Murillo
	Medooze		Medooze
	February 3, 2016		May 2, 2016
	The WebSocket Protocol as a Transport for the Binary Floor Control		The WebSocket Protocol as a Transport for the Binary Floor Control
	Protocol (BFCP)		Protocol (BFCP)
	draft-ietf-bfcpbis-bfcp-websocket-06		draft-ietf-bfcpbis-bfcp-websocket-07
	Abstract		Abstract
	The WebSocket protocol enables two-way realtime communication between		The WebSocket protocol enables two-way realtime communication between
	clients and servers. This document specifies a new WebSocket sub-		clients and servers. This document specifies a new WebSocket sub-
	protocol as a reliable transport mechanism between Binary Floor		protocol as a reliable transport mechanism between Binary Floor
	Control Protocol (BFCP) entities to enable usage of BFCP in new		Control Protocol (BFCP) entities to enable usage of BFCP in new
	scenarios.		scenarios.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 6, 2016.		This Internet-Draft will expire on November 3, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	6. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Updates to RFC4583bis . . . . . . . . . . . . . . . . . . 6		6.1. Updates to RFC4583bis . . . . . . . . . . . . . . . . . . 6
	6.2. Updates to RFC4582bis . . . . . . . . . . . . . . . . . . 6		6.2. Updates to RFC4582bis . . . . . . . . . . . . . . . . . . 6
	6.3. SDP Media Attributes . . . . . . . . . . . . . . . . . . 7		6.3. SDP Media Attributes . . . . . . . . . . . . . . . . . . 7
	7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7		7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7
	7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7		7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.2. Example Usage of 'wss-uri' SDP Attribute . . . . . . . . 7		7.2. Example Usage of 'wss-uri' SDP Attribute . . . . . . . . 7
	8. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8		8. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 9		9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Registration of the WebSocket BFCP Sub-Protocol . . . . 9		10.1. Registration of the WebSocket BFCP Sub-Protocol . . . . 10
	10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP		10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP
	'proto' Values . . . . . . . . . . . . . . . . . . . . . 10		'proto' Values . . . . . . . . . . . . . . . . . . . . . 10
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	12.1. Normative References . . . . . . . . . . . . . . . . . . 10		12.1. Normative References . . . . . . . . . . . . . . . . . . 10
	12.2. Informative References . . . . . . . . . . . . . . . . . 11		12.2. Informative References . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The WebSocket [RFC6455] protocol enables two-way message exchange		The WebSocket [RFC6455] protocol enables two-way message exchange
	between clients and servers on top of a persistent TCP connection,		between clients and servers on top of a persistent TCP connection,
	optionally secured with Transport Layer Security (TLS) [RFC5246].		optionally secured with Transport Layer Security (TLS) [RFC5246].
	The initial protocol handshake makes use of Hypertext Transfer		The initial protocol handshake makes use of Hypertext Transfer
	Protocol (HTTP) [RFC2616] semantics, allowing the WebSocket protocol		Protocol (HTTP) [RFC2616] semantics, allowing the WebSocket protocol
	to reuse existing HTTP infrastructure.		to reuse existing HTTP infrastructure.
	skipping to change at page 5, line 33 ¶		skipping to change at page 5, line 33 ¶
	Sec-WebSocket-Protocol: bfcp		Sec-WebSocket-Protocol: bfcp
	Sec-WebSocket-Version: 13		Sec-WebSocket-Version: 13
	The handshake response from the Server accepting the WebSocket BFCP		The handshake response from the Server accepting the WebSocket BFCP
	sub-protocol would look as follows:		sub-protocol would look as follows:
	HTTP/1.1 101 Switching Protocols		HTTP/1.1 101 Switching Protocols
	Upgrade: websocket		Upgrade: websocket
	Connection: Upgrade		Connection: Upgrade
	Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=		Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
	Sec-WebSocket-Protocol: bfcp		Sec-WebSocket-Protocol: BFCP
	Once the negotiation has been completed, the WebSocket connection is		Once the negotiation has been completed, the WebSocket connection is
	established and can be used for the transport of BFCP messages. The		established and can be used for the transport of BFCP messages. The
	WebSocket messages transmitted over this connection MUST conform to		WebSocket messages transmitted over this connection MUST conform to
	the negotiated WebSocket sub-protocol.		the negotiated WebSocket sub-protocol.
	4.2. BFCP Encoding		4.2. BFCP Encoding
	BFCP messages use a TLV (Type-Length-Value) binary encoding,		BFCP messages use a TLV (Type-Length-Value) binary encoding,
	therefore BFCP WebSocket Clients and BFCP WebSocket Servers MUST be		therefore BFCP WebSocket Clients and BFCP WebSocket Servers MUST be
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 31 ¶
	open the WebSocket connection. The port provided in the 'm' line		open the WebSocket connection. The port provided in the 'm' line
	SHALL be ignored too, as the a=ws-uri or a=wss-uri SHALL provide port		SHALL be ignored too, as the a=ws-uri or a=wss-uri SHALL provide port
	number when needed.		number when needed.
	7. SDP Offer/Answer Procedures		7. SDP Offer/Answer Procedures
	7.1. General		7.1. General
	An endpoint (i.e., both the offerer and the answerer) MUST create an		An endpoint (i.e., both the offerer and the answerer) MUST create an
	SDP media description ("m=" line) for each BFCP-over-WebSocket media		SDP media description ("m=" line) for each BFCP-over-WebSocket media
	stream and MUST assign a TCP/WSS/BFCP value to the "proto" field of		stream and MUST assign either TCP/WSS/BFCP or TCP/WS/BFCP value to
	the "m=" line. Furthermore, the SDP answerer (Server) MUST add an		the "proto" field of the "m=" line depending on whether the endpoint
	"a=ws-uri" or "a=wss-uri" attribute in the "m=" line of each BFCP-		wishes to use secure WebSocket or WebSocket. Furthermore, the server
	over-WebSocket media stream depending on whether it is WS or WSS.		side, whichcould be either the offerer or answerer, MUST add an
	This new attribute MUST follow the syntax defined in		"a=ws-uri" or "a=wss-uri" attribute in the media section depending on
			whether it wishes to use WebSocket or secure WebSocket. This new
			attribute MUST follow the syntax defined in
	[I-D.ram-bfcpbis-sdp-ws-uri]. Additionally, the SDP Offer/Answer		[I-D.ram-bfcpbis-sdp-ws-uri]. Additionally, the SDP Offer/Answer
	procedures defined in Section 4 of [I-D.ram-bfcpbis-sdp-ws-uri] MUST		procedures defined in Section 4 of [I-D.ram-bfcpbis-sdp-ws-uri] MUST
	be followed for the "m=" line associated with a BFCP-over-WebSocket		be followed for the "m=" line associated with a BFCP-over-WebSocket
	media stream.		media stream.
	7.2. Example Usage of 'wss-uri' SDP Attribute		7.2. Example Usage of 'wss-uri' SDP Attribute
	The following is an example of an "m=" line for a BFCP connection.		The following is an example of an "m=" line for a BFCP connection.
	In this example, the offeror sends the SDP with the "proto" field		In this example, the offerer sends the SDP with the "proto" field
	having a value of TCP/WSS/BFCP * indicating that the offeror wishes		having a value of TCP/WSS/BFCP * indicating that the offerer wishes
	to use secure WebSocket as a transport for the media stream.		to use secure WebSocket as a transport for the media stream.
	Offer (browser):		Offer (browser):
	m=application 9 TCP/WSS/BFCP *		m=application 9 TCP/WSS/BFCP *
	a=setup:active		a=setup:active
	a=connection:new		a=connection:new
	a=floorctrl:c-only		a=floorctrl:c-only
	m=audio 55000 RTP/AVP 0		m=audio 55000 RTP/AVP 0
	m=video 55002 RTP/AVP 31		m=video 55002 RTP/AVP 31
	skipping to change at page 8, line 28 ¶		skipping to change at page 8, line 28 ¶
	a=floorctrl:s-only		a=floorctrl:s-only
	a=confid:4321		a=confid:4321
	a=userid:1234		a=userid:1234
	a=floorid:1 m-stream:10		a=floorid:1 m-stream:10
	a=floorid:2 m-stream:11		a=floorid:2 m-stream:11
	m=audio 50002 RTP/AVP 0		m=audio 50002 RTP/AVP 0
	a=label:10		a=label:10
	m=video 50004 RTP/AVP 31		m=video 50004 RTP/AVP 31
	a=label:11		a=label:11
			It is possible that a endpoint (e.g., a browser) sends an offerless
			INVITE to the server. In such cases the server will act as SDP
			offerer. The server MUST assign the SDP "setup" attribute with a
			value of "passive". The server MUST have an "a=ws-uri" or "a=wss-
			uri" attribute in the media section depending on whether the server
			wishes to use WebSocket or secure WebSocket. This attribute MUST
			follow the syntax defined in Section 3. For BFCP application, the
			"proto" value in the "m=" line MUST be TCP/WSS/BFCP if WebSocket is
			over TLS, else it MUST be TCP/WS/BFCP.
	8. Authentication		8. Authentication
	Section 9 of [I-D.ietf-bfcpbis-rfc4582bis] states that BFCP clients		Section 9 of [I-D.ietf-bfcpbis-rfc4582bis] states that BFCP clients
	and floor control servers SHOULD authenticate each other prior to		and floor control servers SHOULD authenticate each other prior to
	accepting messages, and RECOMMENDS that mutual TLS/DTLS		accepting messages, and RECOMMENDS that mutual TLS/DTLS
	authentication be used. However, browser-based WebSocket clients		authentication be used. However, browser-based WebSocket clients
	have no control over the use of TLS in the WebSocket API [WS-API], so		have no control over the use of TLS in the WebSocket API [WS-API], so
	it is RECOMMENDED that standard Web-based methods for client and		it is RECOMMENDED that standard Web-based methods for client and
	server authentication are used, as follows.		server authentication are used, as follows.
	skipping to change at page 10, line 30 ¶		skipping to change at page 10, line 42 ¶
	Figure 1: Values for the SDP 'proto' Field		Figure 1: Values for the SDP 'proto' Field
	[[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to		[[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to
	this specification, and remove this paragraph on publication.]]		this specification, and remove this paragraph on publication.]]
	11. Acknowledgements		11. Acknowledgements
	The authors want to thank Robert Welbourn, from Acme Packet, who made		The authors want to thank Robert Welbourn, from Acme Packet, who made
	significant contributions to the first version of this document.		significant contributions to the first version of this document.
	This work benefited from the thorough review and constructive		This work benefited from the thorough review and constructive
	comments of Charles Eckel and Christer Holmberg.		comments of Charles Eckel, Christer Holmberg and Paul Kyzivat.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-bfcpbis-rfc4582bis]		[I-D.ietf-bfcpbis-rfc4582bis]
	Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C.		Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C.
	Eckel, "The Binary Floor Control Protocol (BFCP)", draft-		Eckel, "The Binary Floor Control Protocol (BFCP)", draft-
	ietf-bfcpbis-rfc4582bis-16 (work in progress), November		ietf-bfcpbis-rfc4582bis-16 (work in progress), November
	2015.		2015.
	[I-D.ietf-bfcpbis-rfc4583bis]		[I-D.ietf-bfcpbis-rfc4583bis]
	Camarillo, G., Kristensen, T., and P. Jones, "Session		Camarillo, G., Kristensen, T., and P. Jones, "Session
	Description Protocol (SDP) Format for Binary Floor Control		Description Protocol (SDP) Format for Binary Floor Control
	Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-12		Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-13
	(work in progress), September 2015.		(work in progress), February 2016.
	[I-D.ram-bfcpbis-sdp-ws-uri]		[I-D.ram-bfcpbis-sdp-ws-uri]
	R, R. and G. Salgueiro, "Session Description Protocol		R, R. and G. Salgueiro, "Session Description Protocol
	(SDP) WebSocket Connection URI Attribute", draft-ram-		(SDP) WebSocket Connection URI Attribute", draft-ram-
	bfcpbis-sdp-ws-uri-01 (work in progress), October 2015.		bfcpbis-sdp-ws-uri-03 (work in progress), February 2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in		[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
	the Session Description Protocol (SDP)", RFC 4145,		the Session Description Protocol (SDP)", RFC 4145,
	DOI 10.17487/RFC4145, September 2005,		DOI 10.17487/RFC4145, September 2005,
	<http://www.rfc-editor.org/info/rfc4145>.		<http://www.rfc-editor.org/info/rfc4145>.
End of changes. 13 change blocks.
	18 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/