rfc9725v4.txt		rfc9725.txt
	skipping to change at line 171 ¶		skipping to change at line 171 ¶
	+-------------+ +---------------+ +--------------+ +---------------+		+-------------+ +---------------+ +--------------+ +---------------+
	| WHIP client | | WHIP endpoint | | Media server | | WHIP session |		| WHIP client | | WHIP endpoint | | Media server | | WHIP session |
	+--+----------+ +---------+-----+ +------+-------+ +--------|------+		+--+----------+ +---------+-----+ +------+-------+ +--------|------+
	| | | |		| | | |
	| | | |		| | | |
	|HTTP POST (SDP offer) | | |		|HTTP POST (SDP offer) | | |
	+------------------------>+ | |		+------------------------>+ | |
	|201 Created (SDP answer) | | |		|201 Created (SDP answer) | | |
	+<------------------------+ | |		+<------------------------+ | |
	| ICE REQUEST | |		| ICE/STUN REQUEST | |
	+--------------------------------------->+ |		+--------------------------------------->+ |
	| ICE RESPONSE | |		| ICE/STUN RESPONSE | |
	|<---------------------------------------+ |		|<---------------------------------------+ |
	| DTLS SETUP | |		| DTLS SETUP | |
	|<======================================>| |		|<======================================>| |
	| RTP/RTCP FLOW | |		| RTP/RTCP FLOW | |
	+<-------------------------------------->+ |		+<-------------------------------------->+ |
	| HTTP DELETE |		| HTTP DELETE |
	+---------------------------------------------------------->+		+---------------------------------------------------------->+
	| 200 OK |		| 200 OK |
	<-----------------------------------------------------------x		<-----------------------------------------------------------x
	skipping to change at line 438 ¶		skipping to change at line 438 ¶
	If the WHIP session supports either Trickle ICE or ICE restarts, but		If the WHIP session supports either Trickle ICE or ICE restarts, but
	not both, it MUST return a "422 Unprocessable Content" error response		not both, it MUST return a "422 Unprocessable Content" error response
	for the HTTP PATCH requests that are not supported as per		for the HTTP PATCH requests that are not supported as per
	Section 15.5.21 of [RFC9110].		Section 15.5.21 of [RFC9110].
	The WHIP client MAY send overlapping HTTP PATCH requests to one WHIP		The WHIP client MAY send overlapping HTTP PATCH requests to one WHIP
	session. Consequently, those HTTP PATCH requests may be received out		session. Consequently, those HTTP PATCH requests may be received out
	of order by the WHIP session. Thus, if the WHIP session supports ICE		of order by the WHIP session. Thus, if the WHIP session supports ICE
	restarts, it MUST generate a unique strong entity-tag identifying the		restarts, it MUST generate a unique strong entity-tag identifying the
	ICE session as per Section 8.8.3 of [RFC9110]. Support of ICE		ICE session as per Section 8.8.3 of [RFC9110]. The initial value of
	restarts is OPTIONAL. The initial value of the entity-tag		the entity-tag identifying the initial ICE session MUST be returned
	identifying the initial ICE session MUST be returned in an ETag		in an ETag header field in the "201 Created" response to the initial
	header field in the "201 Created" response to the initial POST		POST request to the WHIP endpoint.
	request to the WHIP endpoint.
	WHIP clients SHOULD NOT use entity-tag validation when matching a		WHIP clients SHOULD NOT use entity-tag validation when matching a
	specific ICE session is not required, for example, when initiating a		specific ICE session is not required, for example, when initiating a
	DELETE request to terminate a session. WHIP sessions MUST ignore any		DELETE request to terminate a session. WHIP sessions MUST ignore any
	entity-tag value sent by the WHIP client when ICE session matching is		entity-tag value sent by the WHIP client when ICE session matching is
	not required, as in the HTTP DELETE request.		not required, as in the HTTP DELETE request.
	Missing or outdated ETags in the PATCH requests from WHIP clients		Missing or outdated ETags in the PATCH requests from WHIP clients
	will be answered by WHIP sessions as per Section 13.1.1 of [RFC9110]		will be answered by WHIP sessions as per Section 13.1.1 of [RFC9110]
	and Section 3 of [RFC6585], with a "428 Precondition Required"		and Section 3 of [RFC6585], with a "428 Precondition Required"
	skipping to change at line 767 ¶		skipping to change at line 766 ¶
	credentials usable by the client in the "201 Created" response to the		credentials usable by the client in the "201 Created" response to the
	HTTP POST request to the WHIP endpoint URL.		HTTP POST request to the WHIP endpoint URL.
	A reference to each STUN/TURN server will be returned using the Link		A reference to each STUN/TURN server will be returned using the Link
	header field [RFC8288] with a "rel" attribute value of "ice-server".		header field [RFC8288] with a "rel" attribute value of "ice-server".
	The Link target URI is the server URI as defined in [RFC7064] and		The Link target URI is the server URI as defined in [RFC7064] and
	[RFC7065]. The credentials are encoded in the Link target attributes		[RFC7065]. The credentials are encoded in the Link target attributes
	as follows:		as follows:
	* username: If the Link header field represents a Traversal Using		* username: If the Link header field represents a Traversal Using
	Relays around NAT (TURN) server and the "credential-type"		Relays around NAT (TURN) server, then this attribute specifies the
	attribute has a "password" value, then this attribute specifies		username to use with that TURN server.
	the username to use with that TURN server.
	* credential: If the "credential-type" attribute is missing or has a
	"password" value, this attribute represents a long-term
	authentication password, as described in Section 9.2 of [RFC8489].
	* credential-type: If the Link header field represents a TURN		* credential: This attribute represents a long-term authentication
	server, then this attribute specifies how the "credential"		password, as described in Section 9.2 of [RFC8489].
	attribute value should be used when that TURN server requests
	authorization. The default value if the attribute is not present
	is "password".
	Figure 5 illustrates the Link headers included in a "201 Created"		Figure 5 illustrates the Link headers included in a "201 Created"
	response, providing the ICE server URLs and associated credentials.		response, providing the ICE server URLs and associated credentials.
	Link: <stun:stun.example.net>; rel="ice-server"		Link: <stun:stun.example.net>; rel="ice-server"
	Link: <turn:turn.example.net?transport=udp>; rel="ice-server";		Link: <turn:turn.example.net?transport=udp>; rel="ice-server";
	username="user"; credential="myPassword";		username="user"; credential="myPassword"
	credential-type="password"
	Link: <turn:turn.example.net?transport=tcp>; rel="ice-server";		Link: <turn:turn.example.net?transport=tcp>; rel="ice-server";
	username="user"; credential="myPassword";		username="user"; credential="myPassword"
	credential-type="password"
	Link: <turns:turn.example.net?transport=tcp>; rel="ice-server";		Link: <turns:turn.example.net?transport=tcp>; rel="ice-server";
	username="user"; credential="myPassword";		username="user"; credential="myPassword"
	credential-type="password"
	Figure 5: Example of a STUN/TURN Server's Configuration		Figure 5: Example of a STUN/TURN Server's Configuration
	NOTE: The naming of both the "rel" attribute value of "ice-server"		NOTE: The naming of both the "rel" attribute value of "ice-server"
	and the target attributes follows that used in the RTCConfiguration		and the target attributes follows that used in the RTCConfiguration
	dictionary in Section 4.2.1 of the W3C WebRTC recommendation (see		dictionary in Section 4.2.1 of the W3C WebRTC recommendation (see
	[W3C.REC-webrtc-20210126]). The "rel" attribute value of "ice-		[W3C.REC-webrtc-20250313]). The "rel" attribute value of "ice-
	server" is not prepended with the "urn:ietf:params:whip:" so it can		server" is not prepended with the "urn:ietf:params:whip:" so it can
	be reused by other specifications, which may use this mechanism to		be reused by other specifications, which may use this mechanism to
	configure the usage of STUN/TURN servers.		configure the usage of STUN/TURN servers.
	NOTE: Depending on the ICE agent implementation, the WHIP client may		NOTE: Depending on the ICE agent implementation, the WHIP client may
	need to call the setConfiguration method before calling the		need to call the setConfiguration method before calling the
	setLocalDescription method with the local SDP offer in order to avoid		setLocalDescription method with the local SDP offer in order to avoid
	having to perform an ICE restart for applying the updated STUN/TURN		having to perform an ICE restart for applying the updated STUN/TURN
	server configuration on the next ICE gathering phase.		server configuration on the next ICE gathering phase.
	skipping to change at line 1421 ¶		skipping to change at line 1409 ¶
	[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control		[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control
	Requirements for Interactive Real-Time Media", RFC 8836,		Requirements for Interactive Real-Time Media", RFC 8836,
	DOI 10.17487/RFC8836, January 2021,		DOI 10.17487/RFC8836, January 2021,
	<https://www.rfc-editor.org/info/rfc8836>.		<https://www.rfc-editor.org/info/rfc8836>.
	[RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details		[RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
	for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,		for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
	<https://www.rfc-editor.org/info/rfc9457>.		<https://www.rfc-editor.org/info/rfc9457>.
	[W3C.REC-webrtc-20210126]		[W3C.REC-webrtc-20250313]
	Jennings, C., Ed., Castelli, F., Ed., Bostr��m, H., Ed.,		Jennings, C., Ed., Castelli, F., Ed., Bostr��m, H., Ed.,
	and J. Bruaroey, Ed., "WebRTC 1.0: Real-Time Communication		and J. Bruaroey, Ed., "WebRTC: Real-Time Communication in
	Between Browsers", W3C Recommendation, 8 October 2024,		Browsers", W3C Recommendation, 13 March 2025,
	<https://www.w3.org/TR/2024/REC-webrtc-20241008/>. Latest		<https://www.w3.org/TR/2025/REC-webrtc-20250313/>. Latest
	version available at: <https://www.w3.org/TR/webrtc/>.		version available at: <https://www.w3.org/TR/webrtc/>.
	Acknowledgements		Acknowledgements
	The authors wish to thank Lorenzo Miniero, Juliusz Chroboczek, Adam		The authors wish to thank Lorenzo Miniero, Juliusz Chroboczek, Adam
	Roach, Nils Ohlmeier, Christer Holmberg, Cameron Elliott, Gustavo		Roach, Nils Ohlmeier, Christer Holmberg, Cameron Elliott, Gustavo
	Garcia, Jonas Birme, Sandro Gauci, Christer Holmberg, and everyone		Garcia, Jonas Birme, Sandro Gauci, Christer Holmberg, and everyone
	else in the WebRTC community that have provided comments, feedback,		else in the WebRTC community that have provided comments, feedback,
	text, and improvement proposals on the document and contributed early		text, and improvement proposals on the document and contributed early
	implementations of the spec.		implementations of the spec.
End of changes. 11 change blocks.
	30 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.48.