< draft-ietf-wish-whip-00.txt		draft-ietf-wish-whip-01.txt >
	wish S. Murillo		wish S. Murillo
	Internet-Draft A. Gouaillard		Internet-Draft A. Gouaillard
	Intended status: Standards Track CoSMo Software		Intended status: Standards Track CoSMo Software
	Expires: 23 February 2022 22 August 2021		Expires: 23 April 2022 20 October 2021
	WebRTC-HTTP ingestion protocol (WHIP)		WebRTC-HTTP ingestion protocol (WHIP)
	draft-ietf-wish-whip-00		draft-ietf-wish-whip-01
	Abstract		Abstract
	While WebRTC has been very successful in a wide range of scenarios,		While WebRTC has been very sucessful in a wide range of scenarios,
	its adoption in the broadcasting/streaming industry is lagging		its adoption in the broadcasting/streaming industry is lagging
	behind. Currently there is no standard protocol (like SIP or RTSP)		behind. Currently there is no standard protocol (like SIP or RTSP)
	designed for ingesting media in a streaming service, and content		designed for ingesting media into a streaming service using WebRTC
	providers still rely heavily on protocols like RTMP for it.		and so content providers still rely heavily on protocols like RTMP
			for it.
	These protocols are much older than webrtc and lack by default some		These protocols are much older than WebRTC and by default lack some
	important security and resilience features provided by webrtc with		important security and resilience features provided by WebRTC with
	minimal delay.		minimal overhead and additional latency.
	The media codecs used in older protocols do not always match those		The media codecs used for ingestion in older protocols tend to be
	being used in WebRTC, mandating transcoding on the ingest node,		limited and not negotiated. WebRTC includes support for negotiation
	introducing delay and degrading media quality. This transcoding step		of codecs, potentially alleviating transcoding on the ingest node
	is always present in traditional streaming to support e.g. ABR, and		(wich can introduce delay and degrade media quality). Server side
	comes at no cost. However webrtc implements client-side ABR, also		transcoding that has traditionally been done to present multiple
	called Network-Aware Encoding by e.g. Huavision, by means of		renditions in Adaptive Bit Rate Streaming (ABR) implementations can
	simulcast and SVC codecs, which otherwise alleviate the need for		be replaced with simulcasting and SVC codecs that are well supported
	server-side transcoding. Content protection and Privacy Enhancement		by WebRTC clients. In addition, WebRTC clients can adjust client-
	can be achieved with End-to-End Encryption, which preclude any		side encoding parameters based on RTCP feedback to maximize encoding
	server-side media processing.		quality.
			Encryption is mandatory in WebRTC, therefore secure transport of
			media is implicit.
	This document proposes a simple HTTP based protocol that will allow		This document proposes a simple HTTP based protocol that will allow
	WebRTC endpoints to ingest content into streaming services and/or		WebRTC based ingest of content into streaming servics and/or CDNs.
	CDNs to fill this gap and facilitate deployment.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 23 February 2022.		This Internet-Draft will expire on 23 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5		4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5
	4.1. ICE and NAT support . . . . . . . . . . . . . . . . . . . 6		4.1. ICE and NAT support . . . . . . . . . . . . . . . . . . . 6
	4.2. Webrtc constraints . . . . . . . . . . . . . . . . . . . 6		4.2. WebRTC constraints . . . . . . . . . . . . . . . . . . . 8
	4.3. Load balancing and redirections . . . . . . . . . . . . . 7		4.3. Load balancing and redirections . . . . . . . . . . . . . 8
	4.4. STUN/TURN server configuration . . . . . . . . . . . . . 7		4.4. STUN/TURN server configuration . . . . . . . . . . . . . 8
	4.5. Authentication and authorization . . . . . . . . . . . . 7		4.5. Authentication and authorization . . . . . . . . . . . . 9
	4.6. Simulcast and scalable video coding . . . . . . . . . . . 8		4.6. Simulcast and scalable video coding . . . . . . . . . . . 10
	4.7. Protocol extensions . . . . . . . . . . . . . . . . . . . 8		4.7. Protocol extensions . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		6.1. Link Relation Type: urn:ietf:params:whip:ice-server . . . 11
	8. Normative References . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		8. Normative References . . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
			RTCWEB standardized JSEP ([RFC8829]), a mechanishm used to control
			the setup, management, and teardown of a multimedia session, how to
			apply it using the SDP Offer/Answer model and all the formats for the
			data sent over the wire (media, codec, encryption, ...). Also,
	WebRTC intentionally does not specify a signaling transport protocol		WebRTC intentionally does not specify a signaling transport protocol
	at application level, while RTCWEB standardized the signalling		at application level. This flexibility has allowed the
	protocol itself (JSEP, SDP O/A) and everything that was going over		implementation of a wide range of services. However, those services
	the wire (media, codec, encryption, ...). This flexibility has		are typically standalone silos which don't require interoperability
	allowed for implementing a wide range of services. However, those		with other services or leverage the existence of tools that can
	services are typically standalone silos which don't require		communicate with them.
	interoperability with other services or leverage the existence of
	tools that can communicate with them.
	In the broadcasting/streaming world, the usage of hardware encoders		In the broadcasting/streaming world, the usage of hardware encoders
	that would make it very simple to plug in (SDI) cables carrying raw		that make it very simple to plug in (SDI) cables carrying raw media,
	media, encoding it in place, and pushing it to any streaming service		encode it in place, and push it to any streaming service or CDN
	or CDN ingest is ubiquitous. Having to implement a custom signalling		ingest is already ubiquitous. It is the adoption of a custom
	transport protocol for each different webrtc services has hindered		signaling transport protocol for each WebRTC service has hindered
	adoption.		broader adoption as an ingestion protocol.
	While some standard signalling protocols are available that can be		While some standard signaling protocols are available that can be
	integrated with WebRTC, like SIP or XMPP, they are not designed to be		integrated with WebRTC, like SIP or XMPP, they are not designed to be
	used in broadcasting/streaming services, and there also is no sign of		used in broadcasting/streaming services, and there also is no sign of
	adoption in that industry. RTSP, which is based on RTP and maybe the		adoption in that industry. RTSP, which is based on RTP and may be
	closest in terms of features to webrtc, is not compatible with WebRTC		the closest in terms of features to WebRTC, is not compatible with
	SDP offer/answer model.		the WebRTC SDP offer/answer model.
	In the specific case of ingest into a platform, some assumption can		In the specific case of media ingestion into a streaming service,
	be made about the server-side which simplifies the webrtc compliance		some assumptions can be made about the server-side which simplifies
	burden, as detailed in webrtc-gateway document		the WebRTC compliance burden, as detailed in webrtc-gateway document
	[I-D.draft-alvestrand-rtcweb-gateways].		[I-D.draft-alvestrand-rtcweb-gateways].
	This document proposes a simple protocol for supporting WebRTC as		This document proposes a simple protocol for supporting WebRTC as
	ingest method which is:		media ingestion method which is:
	* Easy to implement,		* Easy to implement,
	* As easy to use as current RTMP URIs.		* As easy to use as current RTMP URIs.
	* Fully compliant with Webrtc and RTCWEB specs.		* Fully compliant with WebRTC and RTCWEB specs.
	* Allow for both ingest in traditional media platforms for extension		* Allows for both ingest in traditional media platforms and ingest
	and ingest in webrtc end-to-end platform for lowest possible		in WebRTC end-to-end platforms with the lowest possible latency.
	latency.
	* Lowers the requirements on both hardware encoders and broadcasting		* Lowers the requirements on both hardware encoders and broadcasting
	services to support webrtc.		services to support WebRTC.
	* Usable both in web browsers and in native encoders.		* Usable both in web browsers and in native encoders.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	* WHIP client: WebRTC Media encoder or producer that acts as client		* WHIP client: WebRTC media encoder or producer that acts as a
	on the WHIP protocol and encodes and delivers the media to a		client of the WHIP protocol by encoding and delivering the media
	remote media server.		to a remote media server.
	* WHIP endpoint: Ingest server receiving the initial WHIP request.		* WHIP endpoint: Ingest server receiving the initial WHIP request.
	* WHIP endpoint URL: URL of the WHIP endpoint that will create the		* WHIP endpoint URL: URL of the WHIP endpoint that will create the
	WHIP resource		WHIP resource.
	* Media Server: WebRTC media server that establishes the media		* Media Server: WebRTC media server or consumer that establishes the
	session with the WHIP client and receives the media produced by		media session with the WHIP client and receives the media produced
	it.		by it.
	* WHIP resource: Allocated resource by the WHIP endpoint for an		* WHIP resource: Allocated resource by the WHIP endpoint for an
	ongoing ingest session that the WHIP client can send request for		ongoing ingest session that the WHIP client can send requests for
	altering the session (ICE operations or termination, for example).		altering the session (ICE operations or termination, for example).
	* WHIP resource URL: URL allocated to a specific media session by		* WHIP resource URL: URL allocated to a specific media session by
	the WHIP endpoint which can be used to perform operations such		the WHIP endpoint which can be used to perform operations such as
	terminating the session or ICE restarts.		terminating the session or ICE restarts.
	3. Overview		3. Overview
	The WebRTC-HTTP ingest protocol (WHIP) uses an HTTP POST request to		The WebRTC-HTTP ingest protocol (WHIP) uses an HTTP POST request to
	perform a single shot SDP offer/answer so an ICE/DTLS session can be		perform a single shot SDP offer/answer so an ICE/DTLS session can be
	established between the encoder/media producer and the broadcasting		established between the encoder/media producer (WHIP client) and the
	ingestion endpoint.		broadcasting ingestion endpoint (media server).
	Once the ICE/DTLS session is set up, the media will flow		Once the ICE/DTLS session is set up, the media will flow
	unidirectionally from the encoder/media producer to the broadcasting		unidirectionally from the encoder/media producer (WHIP client) to the
	ingestion endpoint. In order to reduce complexity, no SDP		broadcasting ingestion endpoint (media server). In order to reduce
	renegotiation is supported, so no tracks or streams can be added or		complexity, no SDP renegotiation is supported, so no tracks or
	removed once the initial SDP O/A over HTTP is completed.		streams can be added or removed once the initial SDP offer/answer
			over HTTP is completed.
	+-----------------+ +---------------+ +--------------+ +----------------+		+-----------------+ +---------------+ +--------------+ +----------------+
	| WebRTC Producer | | WHIP endpoint | | Media Server | | WHIP Resource |		| WebRTC Producer | | WHIP endpoint | | Media Server | | WHIP Resource |
	+---------+-------+ +-------+- -----+ +------+-------+ +--------|-------+		+---------+-------+ +-------+- -----+ +------+-------+ +--------|-------+
	| | | |		| | | |
	| | | |		| | | |
	|HTTP POST (SDP Offer) | | |		|HTTP POST (SDP Offer) | | |
	+------------------------>+ | |		+------------------------>+ | |
	|201 Created (SDP answer) | | |		|201 Created (SDP answer) | | |
	+<------------------------+ | |		+<------------------------+ | |
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 36 ¶
	Figure 1: WHIP session setup and teardown		Figure 1: WHIP session setup and teardown
	4. Protocol Operation		4. Protocol Operation
	In order to setup an ingestion session, the WHIP client will generate		In order to setup an ingestion session, the WHIP client will generate
	an SDP offer according to the JSEP rules and do an HTTP POST request		an SDP offer according to the JSEP rules and do an HTTP POST request
	to the WHIP endpoint configured URL.		to the WHIP endpoint configured URL.
	The HTTP POST request will have a content type of application/sdp and		The HTTP POST request will have a content type of application/sdp and
	contain the SDP offer as body. The WHIP endpoint will generate an		contain the SDP offer as the body. The WHIP endpoint will generate
	SDP answer and return it on a 201 Accepted response with content type		an SDP answer and return a 201 Created response with a content type
	of application/sdp and the SDP answer as body and a Location header		of application/sdp and the SDP answer as the body and a Location
	pointing to the newly created resource.		header pointing to the newly created resource.
	SDP offer SHOULD use the sendonly attribute and the SDP answer MUST		The SDP offer SHOULD use the sendonly attribute and the SDP answer
	use the recvonly attribute.		MUST use the recvonly attribute.
	Once a session is setup ICE consent freshness [RFC7675] will be used		Once a session is setup, ICE consent freshness [RFC7675] will be used
	to detect abrupt disconnection and DTLS teardown for session		to detect abrupt disconnection and DTLS teardown for session
	termination by either side.		termination by either side.
	To explicitly terminate the session, the WHIP client MUST perform an		To explicitly terminate the session, the WHIP client MUST perform an
	HTTP DELETE request to the resource url returned on the Location		HTTP DELETE request to the resource URL returned in the Location
	header of the initial HTTP POST. Upon receiving the HTTP DELETE		header of the initial HTTP POST. Upon receiving the HTTP DELETE
	request, the WHIP resource will be removed and the resources freed on		request, the WHIP resource will be removed and the resources freed on
	the media server, terminating the ICE and DTLS sessions.		the media server, terminating the ICE and DTLS sessions.
	A media server terminating a session MUST follow the procedures in		A media server terminating a session MUST follow the procedures in
	[RFC7675] section 5.2 for immediate revocation of consent.		[RFC7675] section 5.2 for immediate revocation of consent.
	The WHIP endpoints MUST return an HTTP 405 response for any HTTP GET,		The WHIP endpoints MUST return an HTTP 405 response for any HTTP GET,
	HEAD or PUT requests on the resource URL in order to reserve its		HEAD or PUT requests on the resource URL in order to reserve its
	usage for future versions of this protocol specification.		usage for future versions of this protocol specification.
	The WHIP resources MUST return an HTTP 405 response for any HTTP GET,		The WHIP resources MUST return an HTTP 405 response for any HTTP GET,
	HEAD, POST or PUT requests on the resource URL in order to reserve		HEAD, POST or PUT requests on the resource URL in order to reserve
	its usage for future versions of this protocol specification.		its usage for future versions of this protocol specification.
	4.1. ICE and NAT support		4.1. ICE and NAT support
	In order to simplify the protocol, there is no support for exchanging
	gathered trickle candidates from media server ICE candidates once the
	SDP answer is sent. So in order to support the WHIP client behind
	NAT, the WHIP media server SHOULD be publicly accessible.
	The initial offer by the WHIP client MAY be sent after the full ICE		The initial offer by the WHIP client MAY be sent after the full ICE
	gathering is complete containing the full list of ICE candidates, or		gathering is complete with the full list of ICE candidates, or only
	only contain local candidates or even an empty list of candidates.		contain local candidates or even an empty list of candidates.
	The WHIP endpoint SDP answer SHALL contain the full list of ICE		In order to simplify the protocol, there is no support for exchanging
	candidates publicly accessible of the media server. The media server		gathered trickle candidates from media server ICE candidates once the
	MAY use ICE lite, while the WHIP client MUST implement full ICE.		SDP answer is sent. The WHIP Endpoint SHALL gather all the ICE
			candidates for the media server before responding to the client
			request and the SDP answer SHALL contain the full list of ICE
			candidates of the media server. The media server MAY use ICE lite,
			while the WHIP client MUST implement full ICE.
	The WHIP client MAY perform trickle ICE or an ICE restarts [RFC8863]		The WHIP client MAY perform trickle ICE or an ICE restarts [RFC8863]
	by sending a HTTP PATCH request to the WHIP resource URL with a body		by sending a HTTP PATCH request to the WHIP resource URL with a body
	containing a SDP fragment with mime type "application/trickle-ice-		containing a SDP fragment with MIME type "application/trickle-ice-
	sdpfrag" as specified in [RFC8840] with the new ice candidate or ice		sdpfrag" as specified in [RFC8840] with the new ICE candidate or ICE
	ufrag/pwd for ice restarts. A WHIP resource MAY not support either		ufrag/pwd for ICE restarts. A WHIP resource MAY not support trickle
	trickle ICE (i.e. ICE lite media servers) or ICE restart, and it		ICE (i.e. ICE lite media servers) or ICE restart, in that case, it
	MUST return a 405 Method Not Allowed for any HTTP PATCH request.		MUST return a 405 Method Not Allowed response for any HTTP PATCH
			request.
	A WHIP client receiving a 405 response for an HTTP PATCH request		A WHIP resource receving a PATH request with new ICE candidates, but
	SHALL not send further request for ICE trickle or restart. If the		which does not perform an ICE restart, MUST return a 204 No content
	WHIP client gathers additional candidates (via STUN/TURN) after the		response without body.
	SDP offer is sent, it MUST send STUN request to the ICE candidates
	received from the media server as per [RFC8838] regardless if the
	HTTP PATCH is supported by either the WHIP client or the WHIP
	resource.
	4.2. Webrtc constraints		PATCH /resource/id HTTP/1.1
			Host: whip.example.com
			Content-Type: application/trickle-ice-sdpfrag
			Content-Length: 548
			a=ice-ufrag:EsAw
			a=ice-pwd:P2uYro0UCOQ4zxjKXaWCBui1
			m=audio RTP/AVP 0
			a=mid:0
			a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host generation 0 ufrag EsAw network-id 1
			a=candidate:3471623853 1 udp 2122194687 198.51.100.1 61765 typ host generation 0 ufrag EsAw network-id 2
			a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype active generation 0 ufrag EsAw network-id 1
			a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host tcptype active generation 0 ufrag EsAw network-id 2
			a=end-of-candidates
			HTTP/1.1 204 No Content
			Figure 2: Trickle ICE request
			If the HTTP PATCH request results in an ICE restart, the WHIP
			resource SHALL return a 200 OK with an "application/trickle-ice-
			sdpfrag" body containing the new ICE username fragment and password
			and, optionaly, the new set of ICE candidates for the media server.
			PATCH /resource/id HTTP/1.1
			Host: whip.example.com
			Content-Type: application/trickle-ice-sdpfrag
			Content-Length: 54
			a=ice-ufrag:ysXw
			a=ice-pwd:vw5LmwG4y/e6dPP/zAP9Gp5k
			HTTP/1.1 200 OK
			Content-Type: application/trickle-ice-sdpfrag
			Content-Length: 102
			a=ice-lite
			a=ice-ufrag:289b31b754eaa438
			a=ice-pwd:0b66f472495ef0ccac7bda653ab6be49ea13114472a5d10a
			Figure 3: ICE restart request
			As the HTTP PATCH request sent by a WHIP client may be received out
			of order by the WHIP resource, the WHIP resource SHOULD keep track of
			the previous values of the ICE username fragment and client used by
			the WHIP client. If an HTTP PATCH request is received with a
			previously used ICE username fragment and password by the client, the
			WHIP endpoint SHALL NOT perform and ICE restart but reject the
			request with a 409 Conflict response instead.
			4.2. WebRTC constraints
	In order to reduce the complexity of implementing WHIP in both		In order to reduce the complexity of implementing WHIP in both
	clients and media servers, some restrictions regarding WebRTC usage		clients and media servers, some restrictions regarding WebRTC usage
	are made.		are made.
	SDP bundle SHALL be used by both the WHIP client and the media		SDP bundle SHALL be used by both the WHIP client and the media
	server. The SDP offer created by the WHIP client MUST include the		server. The SDP offer created by the WHIP client MUST include the
	bundle-only attribute in all m-lines as per [RFC8843]. Also, RTCP		bundle-only attribute in all m-lines as per [RFC8843]. Also, RTCP
	muxing SHALL be supported by both the WHIP client and the media		muxing SHALL be supported by both the WHIP client and the media
	server.		server.
	Unlike [RFC5763] a WHIP client MAY use a setup attribute value of		Unlike [RFC5763] a WHIP client MAY use a setup attribute value of
	setup:active in the SDP offer, in which case the WHIP endpoint MUST		setup:active in the SDP offer, in which case the WHIP endpoint MUST
	use a setup attribute value of setup:passive in the SDP answer.		use a setup attribute value of setup:passive in the SDP answer.
	4.3. Load balancing and redirections		4.3. Load balancing and redirections
	WHIP endpoints and media servers MAY not be colocated on the same		WHIP endpoints and media servers MAY not be colocated on the same
	server so it is possible to load balance incoming requests to		server so it is possible to load balance incoming requests to
	different media servers. WHIP clients SHALL support HTTP redirection		different media servers. WHIP clients SHALL support HTTP redirection
	via 307 Temporary Redirect response code.		via the 307 Temporary Redirect response code in the initial HTTP
			response to the WHIP endpoint URL. The WHIP resource URL MUST be a
			final one, and redirections are not required to be supported for the
			PATCH and DELETE request sent to it.
	In case of high load, the WHIP endpoints may return a 503 (Service		In case of high load, the WHIP endpoints MAY return a 503 (Service
	Unavailable) status code indicating that the server is currently		Unavailable) status code indicating that the server is currently
	unable to handle the request due to a temporary overload or scheduled		unable to handle the request due to a temporary overload or scheduled
	maintenance, which will likely be alleviated after some delay.		maintenance, which will likely be alleviated after some delay.
	The WHIP endpoint MAY send a Retry-After header field indicating the		The WHIP endpoint MAY send a Retry-After header field indicating the
	minimum time that the user agent is asked to wait before issuing the		minimum time that the user agent is asked to wait before issuing the
	redirected request.		redirected request.
	4.4. STUN/TURN server configuration		4.4. STUN/TURN server configuration
	Configuration of the TURN or STUN servers used by the WHIP client is		The WHIP endpoint MAY return ICE server configuration urls and
	out of the scope of this document.		credentials usable by the client in the 201 Created response to the
			HTTP POST request to the WHIP endpoint url.
	It is RECOMMENDED that broadcasting server provides an HTTP interface		Each ICE server will be returned on a Link header with a "rel"
	for provisioning the TUNR/STUN servers url and short term credentiasl		attribribute value of "ice-server" where the Link target URI is the
	as in [I-D.draft-uberti-behave-turn-rest-00]. Note that the		ICE server URL and the credentials are encoded in the Link target
	authentication information or the url of this API are not related to		attributes as follows:
	the WHIP enpoint URLs or authentication.
	It could also be possilble to configure the STUN/TURN server URLS and		* username: If this the Link header represents a TURN server, and
	long term credentials provided by the either broadcasting service or		creadential-type is "password", then this attribute specifies the
	an external TURN provider.		username to use with that TURN server.
			* credential: If credentialType is "password", credential represents
			a long-term authentication password, as described in [RFC8489],
			Section 10.2.
			* creadential-type: If this RTCIceServer object represents a TURN
			server, then this attribute specifies how credential should be
			used when that TURN server requests authorization. The default
			value if the attribute is not present is "password".
			Link: stun:stun.example.net;
			Link: turn:turn.example.net?transport=udp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password";
			Link: turn:turn.example.net?transport=tcp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password";
			Link: turns:turn.example.net?transport=tcp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password";
			Figure 4: Example ICE server configuration
			There are some webrtc implementations that do not support updating
			the ICE server configuration after the local offer has been created.
			In order to support these clients, the WHIP endpoint MAY also include
			the ICE server configuration on the responses to an authenticated
			OPTIONS request sent to the WHIP endpoint URL sent before the POST
			requests.
			It COULD be also possible to configure the STUN/TURN server URLs with
			long term credentials provided by either the broadcasting service or
			an external TURN provider on the WHIP client overriding the values
			provided by the WHIP endpoint.
	4.5. Authentication and authorization		4.5. Authentication and authorization
	Authentication and authorization is supported by the Authorization		WHIP endpoints and resources MAY require the HTTP request to be
	HTTP header with a bearer token as per [RFC6750].		authenticated using an HTTP Authorization header with a Bearer token
			as specified in [RFC6750] section 2.1. WHIP clients MUST implemenent
			this authentication and authorization mechanism and send the HTTP
			Authorization header in all HTTP request sent to either the WHIP
			endpoint or resource.
			The nature, syntax and semantics of the bearer token as well as how
			to distribute it to the client is outside the scope of this document.
			Some examples ot the kind of tokens that could be used are, but are
			not limited to, JWT tokens as per [RFC6750] and [RFC8725] or a shared
			secret stored on a database. The tokens are typically made available
			to the end user alongside the WHIP endpoint url and configured on the
			WHIP clients.
			WHIP endpoints and resources COULD perform the authentication and
			authorization by encoding an authentication token withing the urls
			for the WHIP endpoints or resources instead. In case the WHIP client
			is not configured to use a bearer token the HTTP Authorization header
			must not be sent in any request.
	4.6. Simulcast and scalable video coding		4.6. Simulcast and scalable video coding
	Both simulcast and scalable video coding (including K-SVC modes) MAY		Both simulcast and scalable video coding (including K-SVC modes) MAY
	be supported by both media servers and WHIP clients and negotiated in		be supported by both the media servers and WHIP clients through
	the SDP O/A.		negotiation in the SDP offer/answer.
	If the client supports simulcast and wants to enable it for		If the client supports simulcast and wants to enable it for
	publishing, it MUST negotiate the support in the SDP offer according		publishing, it MUST negotiate the support in the SDP offer according
	to the procedures in [RFC8853] section 5.3. A server accepting a		to the procedures in [RFC8853] section 5.3. A server accepting a
	simulcast offer MUST create an answer accoding to the procedures		simulcast offer MUST create an answer accoding to the procedures
	[RFC8853] section 5.3.2.		[RFC8853] section 5.3.2.
	4.7. Protocol extensions		4.7. Protocol extensions
	In order to support future extensions to be defined for the WHIP		In order to support future extensions to be defined for the WHIP
	protocol, a common procedure for registering and announcing the new		protocol, a common procedure for registering and announcing the new
	extensions is defined.		extensions is defined.
	Protocol extensions supported by the WHIP server MUST be advertised		Protocol extensions supported by the WHIP server MUST be advertised
	to the WHIP client on the 201 created response to initial HTTP POST		to the WHIP client on the 201 Created response to the initial HTTP
	request to the WHIP enpoint by inserting one Link header for each		POST request sent to the WHIP endpoint. The WHIP endpoint MUST
	extension with the extension "rel" type attribute and the uri for the		return one Link header for each extension with the extension "rel"
	HTTP resource that will be available for receiving request related to		type attribute and the URI for the HTTP resource that will be
	that extension.		available for receiving requests related to that extension.
	Protocol extensions are optionasl for bot WHIP clients and servers.		Protocol extensions are optional for both WHIP clients and servers.
	WHIP clients MUST ignore any Link attribute with an unknown "rel"		WHIP clients MUST ignore any Link attribute with an unknown "rel"
	attribute value and WHIP servers MUST not require the usage of any of		attribute value and WHIP servers MUST NOT require the usage of any of
	the extensions.		the extensions.
	Each protocol extension MUST register an unique "rel" attribute		Each protocol extension MUST register an unique "rel" attribute
	values at IANA starting with the prefix: "urn:ietf:params:whip:".		values at IANA starting with the prefix: "urn:ietf:params:whip:".
	For example, taking a potential extension of server to client		For example, taking a potential extension of server to client
	communication using server sent events as specified in		communication using server sent events as specified in
	https://html.spec.whatwg.org/multipage/server-sent-		https://html.spec.whatwg.org/multipage/server-sent-
	events.html#server-sent-events, the url for connecting to the server		events.html#server-sent-events, the URL for connecting to the server
	side event resource for the published stream will be returned in the		side event resource for the published stream will be returned in the
	initial HTTP "201 Created" response with a "Link" header an a "rel"		initial HTTP "201 Created" response with a "Link" header and a "rel"
	attribute of "urn:ietf:params:whip:server-sent-events".		attribute of "urn:ietf:params:whip:server-sent-events".
	The HTTP 201 response to the HTTP POST request would look like:		The HTTP 201 response to the HTTP POST request would look like:
	HTTP/1.1 201 Created		HTTP/1.1 201 Created
	Content-Type: application/sdp		Content-Type: application/sdp
	Location: https://whip.ietf.org/publications/213786HF		Location: https://whip.example.org/resource/id
	Link: <https://whip.ietf.org/publications/213786HF/sse>;rel="urn:ietf:params:whip:server-side-events "		Link: <https://whip.ietf.org/publications/213786HF/sse>;rel="urn:ietf:params:whip:server-side-events"
	5. Security Considerations		5. Security Considerations
	HTTPS SHALL be used in order to preserve the WebRTC security model.		HTTPS SHALL be used in order to preserve the WebRTC security model.
	6. IANA Considerations		6. IANA Considerations
			The link relation types below have been registered by IANA per
			Section 4.2 of [RFC8288].
			6.1. Link Relation Type: urn:ietf:params:whip:ice-server
			Relation Name: ice-server Description: Describe the STUN and TURN
			servers that can be used by the ICE Agent to establish a connection
			with a peer. Reference: TBD
	7. Acknowledgements		7. Acknowledgements
	8. Normative References		8. Normative References
	[I-D.draft-alvestrand-rtcweb-gateways]		[I-D.draft-alvestrand-rtcweb-gateways]
	Alvestrand, H. and U. Rauschenbach, "WebRTC Gateways",		Alvestrand, H. and U. Rauschenbach, "WebRTC Gateways",
	Work in Progress, Internet-Draft, draft-alvestrand-rtcweb-		Work in Progress, Internet-Draft, draft-alvestrand-rtcweb-
	gateways-02, 9 March 2015,		gateways-02, 9 March 2015,
	<https://www.ietf.org/archive/id/draft-alvestrand-rtcweb-		<https://www.ietf.org/archive/id/draft-alvestrand-rtcweb-
	gateways-02.txt>.		gateways-02.txt>.
	[I-D.draft-uberti-behave-turn-rest-00]
	Uberti, J., "A REST API For Access To TURN Services", Work
	in Progress, Internet-Draft, draft-uberti-behave-turn-
	rest-00, 15 July 2013, <http://www.ietf.org/internet-
	drafts/draft-uberti-behave-turn-rest-00.txt>.
	[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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
	for Establishing a Secure Real-time Transport Protocol		for Establishing a Secure Real-time Transport Protocol
	(SRTP) Security Context Using Datagram Transport Layer		(SRTP) Security Context Using Datagram Transport Layer
	Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May		Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
	2010, <https://www.rfc-editor.org/info/rfc5763>.		2010, <https://www.rfc-editor.org/info/rfc5763>.
	skipping to change at page 10, line 5 ¶		skipping to change at page 12, line 21 ¶
	[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization		[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
	Framework: Bearer Token Usage", RFC 6750,		Framework: Bearer Token Usage", RFC 6750,
	DOI 10.17487/RFC6750, October 2012,		DOI 10.17487/RFC6750, October 2012,
	<https://www.rfc-editor.org/info/rfc6750>.		<https://www.rfc-editor.org/info/rfc6750>.
	[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.		[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
	Thomson, "Session Traversal Utilities for NAT (STUN) Usage		Thomson, "Session Traversal Utilities for NAT (STUN) Usage
	for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,		for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
	October 2015, <https://www.rfc-editor.org/info/rfc7675>.		October 2015, <https://www.rfc-editor.org/info/rfc7675>.
	[RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:		[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
	Incremental Provisioning of Candidates for the Interactive		DOI 10.17487/RFC8288, October 2017,
	Connectivity Establishment (ICE) Protocol", RFC 8838,		<https://www.rfc-editor.org/info/rfc8288>.
	DOI 10.17487/RFC8838, January 2021,
	<https://www.rfc-editor.org/info/rfc8838>.		[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
			D., Mahy, R., and P. Matthews, "Session Traversal
			Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489,
			February 2020, <https://www.rfc-editor.org/info/rfc8489>.
			[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
			Current Practices", BCP 225, RFC 8725,
			DOI 10.17487/RFC8725, February 2020,
			<https://www.rfc-editor.org/info/rfc8725>.
			[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed.,
			"JavaScript Session Establishment Protocol (JSEP)",
			RFC 8829, DOI 10.17487/RFC8829, January 2021,
			<https://www.rfc-editor.org/info/rfc8829>.
	[RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A		[RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
	Session Initiation Protocol (SIP) Usage for Incremental		Session Initiation Protocol (SIP) Usage for Incremental
	Provisioning of Candidates for the Interactive		Provisioning of Candidates for the Interactive
	Connectivity Establishment (Trickle ICE)", RFC 8840,		Connectivity Establishment (Trickle ICE)", RFC 8840,
	DOI 10.17487/RFC8840, January 2021,		DOI 10.17487/RFC8840, January 2021,
	<https://www.rfc-editor.org/info/rfc8840>.		<https://www.rfc-editor.org/info/rfc8840>.
	[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings,		[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings,
	"Negotiating Media Multiplexing Using the Session		"Negotiating Media Multiplexing Using the Session
End of changes. 53 change blocks.
	143 lines changed or deleted		261 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/