< draft-ietf-bfcpbis-sdp-ws-uri-01.txt		draft-ietf-bfcpbis-sdp-ws-uri-02.txt >
	BFCPBIS Working Group Ram. Ravindranath		BFCPBIS Working Group Ram. Ravindranath
	Internet-Draft G. Salgueiro		Internet-Draft G. Salgueiro
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Expires: August 31, 2016 February 28, 2016		Expires: November 3, 2016 May 2, 2016
	Session Description Protocol (SDP) WebSocket Connection URI Attribute		Session Description Protocol (SDP) WebSocket Connection URI Attribute
	draft-ietf-bfcpbis-sdp-ws-uri-01		draft-ietf-bfcpbis-sdp-ws-uri-02
	Abstract		Abstract
	The WebSocket protocol enables bidirectional real-time communication		The WebSocket protocol enables bidirectional real-time communication
	between clients and servers in web-based applications. This document		between clients and servers in web-based applications. This document
	specifies extensions to Session Description Protocol (SDP) for		specifies extensions to Session Description Protocol (SDP) for
	application protocols using WebSocket as a transport.		application protocols using WebSocket as a transport.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 31, 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 20 ¶		skipping to change at page 2, line 20 ¶
	3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. ws-uri SDP Attribute . . . . . . . . . . . . . . . . . . 3		3.2. ws-uri SDP Attribute . . . . . . . . . . . . . . . . . . 3
	3.3. wss-uri SDP Attribute . . . . . . . . . . . . . . . . . . 4		3.3. wss-uri SDP Attribute . . . . . . . . . . . . . . . . . . 4
	3.4. ws-uri and wss-uri Multiplexing Considerations . . . . . 4		3.4. ws-uri and wss-uri Multiplexing Considerations . . . . . 4
	4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5		4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5
	4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Generating the Initial Offer . . . . . . . . . . . . . . 5		4.2. Generating the Initial Offer . . . . . . . . . . . . . . 5
	4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 6		4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 6
	4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7		4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7
	4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 7		4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		4.6. Offerless INVITE Scenarios . . . . . . . . . . . . . . . 7
			5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The WebSocket protocol [RFC6455] enables bidirectional message		The WebSocket protocol [RFC6455] enables bidirectional message
	exchange between clients and servers on top of a persistent TCP		exchange between clients and servers on top of a persistent TCP
	connection (optionally secured with Transport Layer Security (TLS)		connection (optionally secured with Transport Layer Security (TLS)
	[RFC5246]). The initial protocol handshake makes use of Hypertext		[RFC5246]). The initial protocol handshake makes use of Hypertext
	Transfer Protocol (HTTP) [RFC2616] semantics, allowing the WebSocket		Transfer Protocol (HTTP) [RFC7235] semantics, allowing the WebSocket
	protocol to reuse existing HTTP infrastructure.		protocol to reuse existing HTTP infrastructure.
	Modern web browsers include a WebSocket client stack compliant with		Modern web browsers include a WebSocket client stack compliant with
	the WebSocket API [WS-API] as specified by the W3C. It is expected		the WebSocket API [WS-API] as specified by the W3C. It is expected
	that other client applications (e.g., those running on personal		that other client applications (e.g., those running on personal
	computers, mobile devices, etc.) will also make a WebSocket client		computers, mobile devices, etc.) will also make a WebSocket client
	stack available. Several specifications have been written that		stack available. Several specifications have been written that
	define how different applications can use a WebSocket subprotocol as		define how different applications can use a WebSocket subprotocol as
	a reliable transport mechanism.		a reliable transport mechanism.
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 47 ¶
	media-level attribute defined in Section 3.2.		media-level attribute defined in Section 3.2.
	Applications that use SDP for negotiation and also use secure		Applications that use SDP for negotiation and also use secure
	WebSocket as a transport protocol TLS MAY indicate the connection URI		WebSocket as a transport protocol TLS MAY indicate the connection URI
	for the WebSocket Client via a new SDP a= media-level attribute		for the WebSocket Client via a new SDP a= media-level attribute
	defined in Section 3.3.		defined in Section 3.3.
	3.2. ws-uri SDP Attribute		3.2. ws-uri SDP Attribute
	This section defines a new SDP media-level attribute, 'ws-uri' which		This section defines a new SDP media-level attribute, 'ws-uri' which
	can appear in any of the media lines.		can appear in any of the media sections.
	Name : ws-uri		Name : ws-uri
	Value: ws-uri (defined in Section 3 of [RFC6455])		Value: ws-uri (defined in Section 3 of [RFC6455])
	Usage Level: media		Usage Level: media
	Mux Category: NOT RECOMMENDED		Mux Category: NOT RECOMMENDED
	Charset Dependent: no		Charset Dependent: no
	skipping to change at page 4, line 23 ¶		skipping to change at page 4, line 23 ¶
	When the 'ws-uri' attribute is present in the media section of the		When the 'ws-uri' attribute is present in the media section of the
	SDP, the IP address in 'c= ' line SHALL be ignored and the full URI		SDP, the IP address in 'c= ' line SHALL be ignored and the full URI
	SHALL be used instead to open the WebSocket connection. The port		SHALL be used instead to open the WebSocket connection. The port
	provided in the 'm= ' line SHALL be ignored too, as the 'a=ws-uri'		provided in the 'm= ' line SHALL be ignored too, as the 'a=ws-uri'
	SHALL provide port number when needed.		SHALL provide port number when needed.
	3.3. wss-uri SDP Attribute		3.3. wss-uri SDP Attribute
	This section defines a new SDP media-level attribute, 'wss-uri' which		This section defines a new SDP media-level attribute, 'wss-uri' which
	can appear in any of the media lines.		can appear in any of the media sections.
	Name : wss-uri		Name : wss-uri
	Value: wss-uri (defined in Section 3 of [RFC6455])		Value: wss-uri (defined in Section 3 of [RFC6455])
	Usage Level: media		Usage Level: media
	Mux Category: NOT RECOMMENDED		Mux Category: NOT RECOMMENDED
	Charset Dependent: no		Charset Dependent: no
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 32 ¶
	rules for the "a=ws-uri:" and "a=wss-uri:" attributes need to be		rules for the "a=ws-uri:" and "a=wss-uri:" attributes need to be
	defined as well, for instance in an extension of this SDP based		defined as well, for instance in an extension of this SDP based
	WebSocket negotiation specification.		WebSocket negotiation specification.
	4. SDP Offer/Answer Procedures		4. SDP Offer/Answer Procedures
	4.1. General		4.1. General
	An endpoint (i.e., both the offerer and the answerer) that wishes to		An endpoint (i.e., both the offerer and the answerer) that wishes to
	negotiate WebSocket as transport protocol MUST indicate that it		negotiate WebSocket as transport protocol MUST indicate that it
	wishes to use WebSocket or secureWebSocket in the "proto" field of		wishes to use WebSocket or secure WebSocket in the "proto" field of
	the "m=" line. Furthermore, the SDP answerer MUST add an "a=ws-uri"		the "m=" line. Furthermore, the server side, which could be either
	or "a=wss-uri" attribute in the "m=" line of each media-line		the offerer or answerer, MUST add an "a=ws-uri" or "a=wss-uri"
	depending on whether the "proto" field has WebSocket or		attribute in the media section depending on whether it wishes to use
	secureWebSocket. This new attribute MUST follow the syntax defined		WebSocket or secure WebSocket. This new attribute MUST follow the
	in Section 3. The procedures in this section apply to an "m=" line		syntax defined in Section 3. The procedures in this section apply to
	associated with any media stream that uses WebSocket or		an "m=" line associated with any media stream that uses WebSocket or
	secureWebSocket as transport.		secure WebSocket as transport.
	4.2. Generating the Initial Offer		4.2. Generating the Initial Offer
	An SDP offerer in order to negotiate WebSocket as a transport MUST		An SDP offerer in order to negotiate WebSocket as a transport MUST
	indicate the same in the "proto" field of the "m=" line. For		indicate the same in the "proto" field of the "m=" line. For
	example, to negotiate BFCP-over-WebSocket the "proto" value in the		example, to negotiate BFCP-over-WebSocket the "proto" value in the
	"m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST		"m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST
	be TCP/WS/BFCP.		be TCP/WS/BFCP.
	The offerer SHOULD assign the SDP "setup" attribute with a value of		The offerer SHOULD assign the SDP "setup" attribute with a value of
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 47 ¶
	in [RFC6455]. The answer MUST have an "a=ws-uri" or "a=wss-uri"		in [RFC6455]. The answer MUST have an "a=ws-uri" or "a=wss-uri"
	attribute depending on whether the application is run of WS or WSS.		attribute depending on whether the application is run of WS or WSS.
	This attribute MUST follow the syntax defined in Section 3. For BFCP		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		application, the "proto" value in the "m=" line MUST be TCP/WSS/BFCP
	if WebSocket is run on TLS, else it MUST be TCP/WS/BFCP.		if WebSocket is run on TLS, else it MUST be TCP/WS/BFCP.
	The following example shows a case where the server responds with a		The following example shows a case where the server responds with a
	BFCP media stream over a WebSocket connection running TLS. It shows		BFCP media stream over a WebSocket connection running TLS. It shows
	an answer "m=" line for the BFCP connection. In this example since		an answer "m=" line for the BFCP connection. In this example since
	WebSockets is running over TLS, the server answers back with "a=wss-		WebSockets is running over TLS, the server answers back with "a=wss-
	uri" attribute in SDP indicating the connection URI:		uri" attribute in the media section of SDP indicating the connection
			URI:
	Answer (server):		Answer (server):
	m=application 50000 TCP/WSS/BFCP *		m=application 50000 TCP/WSS/BFCP *
	a=setup:passive		a=setup:passive
	a=connection:new		a=connection:new
	a=wss-uri:wss://bfcp-ws.example.com?token=3170449312		a=wss-uri:wss://bfcp-ws.example.com?token=3170449312
	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
	skipping to change at page 7, line 32 ¶		skipping to change at page 7, line 32 ¶
	When the offerer receives an SDP answer, if the offerer ends up being		When the offerer receives an SDP answer, if the offerer ends up being
	active it MUST initiate the WebSocket connection handshake by sending		active it MUST initiate the WebSocket connection handshake by sending
	a GET message on the negotiated media stream, towards the IP address		a GET message on the negotiated media stream, towards the IP address
	and port of the answerer, as per the procedures described in		and port of the answerer, as per the procedures described in
	[RFC6455].		[RFC6455].
	4.5. Modifying the Session		4.5. Modifying the Session
	Once an offer/answer exchange has been completed, either endpoint MAY		Once an offer/answer exchange has been completed, either endpoint MAY
	send a new offer in order to modify the session. The endpoints can		send a new offer in order to modify the session. The endpoints can
	reuse the existing WebSocket connection if the ws-uri values and the		reuse the existing WebSocket connection by adding
	transport parameters indicated by each endpoint are unchanged.		"a=connection:existing" attribute in the media section of SDP
			following the rules mentioned in [RFC4145] if the ws-uri values and
			the transport parameters indicated by each endpoint are unchanged.
	Otherwise, following the rules for the initial offer/answer exchange,		Otherwise, following the rules for the initial offer/answer exchange,
	the endpoints can negotiate and create a new WebSocket connection on		the endpoints can negotiate and create a new WebSocket connection on
	top of TLS/TCP or TCP.		top of TLS/TCP or TCP.
			4.6. Offerless INVITE Scenarios
			In some scenarios an endpoint (e.g., a browser) originating the call
			(UAC) can send an offerless INVITE to the server. The server will
			generate an offer in response to the INVITE. In such cases the
			server MUST send an offer with setup attribute as "passive" so as to
			accept incoming connection and MUST include "a=wss-uri" or "a=ws-uri"
			attribute in the media section depending on whether the server wishes
			to use WebSocket or secure WebSocket. The SDP offer sent by the
			server will look like the example in Section 4.3.
	5. Security Considerations		5. Security Considerations
	An attacker may attempt to add, modify, or remove 'a=ws-uri' or		An attacker may attempt to add, modify, or remove 'a=ws-uri' or
	'a=wss-uri' attribute from a session description. This could result		'a=wss-uri' attribute from a session description. This could result
	in an application behaving undesirably. Consequently, it is strongly		in an application behaving undesirably. Consequently, it is strongly
	RECOMMENDED that integrity protection be applied to the SDP session		RECOMMENDED that integrity protection be applied to the SDP session
	descriptions. For session descriptions carried in SIP [RFC3261], S/		descriptions. For session descriptions carried in SIP [RFC3261], S/
	MIME is the natural choice to provide such end-to-end integrity		MIME is the natural choice to provide such end-to-end integrity
	protection.		protection.
	skipping to change at page 8, line 20 ¶		skipping to change at page 8, line 34 ¶
	This document requests that IANA to register the attributes defined		This document requests that IANA to register the attributes defined
	in Section 3.2 and Section 3.3 as new values for the SDP att-field		in Section 3.2 and Section 3.3 as new values for the SDP att-field
	under the Session Description Protocol (SDP) Parameters registry,		under the Session Description Protocol (SDP) Parameters registry,
	with RFCXXXX as the reference.		with RFCXXXX as the reference.
	7. Acknowledgements		7. Acknowledgements
	Thanks to Christer Holmberg for raising the need for a BFCP-		Thanks to Christer Holmberg for raising the need for a BFCP-
	independent SDP attribute for WebSocket Connection URI.		independent SDP attribute for WebSocket Connection URI.
	The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar, and		The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar and
	Christer Holmberg for their invaluable suggestions and review		Christer Holmberg for their invaluable suggestions and review
	comments.		comments.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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,
	skipping to change at page 9, line 22 ¶		skipping to change at page 9, line 35 ¶
	Nandakumar, S., "A Framework for SDP Attributes when		Nandakumar, S., "A Framework for SDP Attributes when
	Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12		Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
	(work in progress), January 2016.		(work in progress), January 2016.
	[I-D.pd-dispatch-msrp-websocket]		[I-D.pd-dispatch-msrp-websocket]
	Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G.,		Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G.,
	and R. R, "The WebSocket Protocol as a Transport for the		and R. R, "The WebSocket Protocol as a Transport for the
	Message Session Relay Protocol (MSRP)", draft-pd-dispatch-		Message Session Relay Protocol (MSRP)", draft-pd-dispatch-
	msrp-websocket-10 (work in progress), February 2016.		msrp-websocket-10 (work in progress), February 2016.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616,
	DOI 10.17487/RFC2616, June 1999,
	<http://www.rfc-editor.org/info/rfc2616>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<http://www.rfc-editor.org/info/rfc2818>.		<http://www.rfc-editor.org/info/rfc2818>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<http://www.rfc-editor.org/info/rfc3261>.		<http://www.rfc-editor.org/info/rfc3261>.
	skipping to change at page 10, line 16 ¶		skipping to change at page 10, line 21 ¶
	Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,		Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
	DOI 10.17487/RFC6101, August 2011,		DOI 10.17487/RFC6101, August 2011,
	<http://www.rfc-editor.org/info/rfc6101>.		<http://www.rfc-editor.org/info/rfc6101>.
	[RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual,		[RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual,
	"The WebSocket Protocol as a Transport for the Session		"The WebSocket Protocol as a Transport for the Session
	Initiation Protocol (SIP)", RFC 7118,		Initiation Protocol (SIP)", RFC 7118,
	DOI 10.17487/RFC7118, January 2014,		DOI 10.17487/RFC7118, January 2014,
	<http://www.rfc-editor.org/info/rfc7118>.		<http://www.rfc-editor.org/info/rfc7118>.
			[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Authentication", RFC 7235,
			DOI 10.17487/RFC7235, June 2014,
			<http://www.rfc-editor.org/info/rfc7235>.
	[RFC7395] Stout, L., Ed., Moffitt, J., and E. Cestari, "An		[RFC7395] Stout, L., Ed., Moffitt, J., and E. Cestari, "An
	Extensible Messaging and Presence Protocol (XMPP)		Extensible Messaging and Presence Protocol (XMPP)
	Subprotocol for WebSocket", RFC 7395,		Subprotocol for WebSocket", RFC 7395,
	DOI 10.17487/RFC7395, October 2014,		DOI 10.17487/RFC7395, October 2014,
	<http://www.rfc-editor.org/info/rfc7395>.		<http://www.rfc-editor.org/info/rfc7395>.
	[WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012.		[WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012.
	Authors' Addresses		Authors' Addresses
End of changes. 15 change blocks.
	26 lines changed or deleted		40 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/