Change:
4.4. <del> The WHIP endpoint MAY return ICE server configuration URLs and </del> <ins> The WHIP endpoint MAY return STUN/TURN server configuration URLs and </ins> credentials usable by the client in the "201 Created" response to the HTTP POST request to the WHIP endpoint URL. <del> Each ICE server will be returned using the "Link" header field RFC8288 with a "rel" attribute value of "ice-server".  The Link target URI will contain the ICE server URL.  The credentials are encoded in the Link target attributes as follows: </del> <ins> Each STUN/TURN server will be returned using the "Link" header field RFC8288 with a "rel"" attribute value of "ice-server".  The Link target URI is the server URL as defined in RFC7064 and RFC7065.  The credentials are encoded in the Link target attributes as follows: </ins> username: If the Link header field represents a TURN server, and credential-type is "password", then this attribute specifies the

Discussion:
NAME wdyt?
he usability of the ICE server configuration seem to go far beyond WHIP. Also, in my opinion the way you configure your STUN/TURN servers is slightly outside the scope of core WHIP. But, assuming you want to keep the text: First, you should add references to where the STUN- and TURN server URIs are defined. Second, I believe Link URIs have to be enclosed by . Third, I think the "ice-server" value is misleading. An ICE server is not the same thing as a STUN/TURN server. You don't even have to use ICE in order to support STUN/TURN. Fourth, related to the third issue, perhaps you should use the "urn:ietf:params:whip:" appendix also for the STUN/TURN servers? Fifth, you say that not all webrtc implementations may allow STUN/TURN server re-configuring after the offer has been created. But, does WebRTC even define a mechanism to programmatically configure the servers? If so, please add a reference. If not, please indicate that.
Using WHIP without a valid TURN/STUN server configuration will fail in many cases, so In practice any WHIP service provider will also be providing STUN/TURN services to be used with. WHIP allows sending the STUN/TURN server configuration in the HTTP request in order to not have to manualy configure the configuration manually o the client. Moreover, some WHIP providers may want to restrict the usage of their TURN/STUN server and only provide short lived credentials that are only valid in the context of the WHIP session. The term is taken from the W3C webrtc spec that uses the configuration property when creating the PC. Regarding the and , yes, it is a typo and should be corrected. Regarding the it was originally propossed like that but i was agreed that this could be used to configure other webrtc services and not only WHIP and it could be better to not have the urn be whip-specific WebRTC w3c spec supports reconfiguration of the stun/turn server connection via URL
Won't the WHIP servers have a publicly available IP address in most cases? And, as the WHIP client is the one always establishing the media path, there should be no need for a STUN/TURN server in such cases.

Or? Ok. I suggest adding a note to indicate that. I suggest adding some text and point that out. Thanks! I suggest adding a reference,
Clients may be behind restricted firewalls which block UDP. It is easier to just deploy a TURN server to do TURN over TCP/TLS than implement ICE TCP on the media server (and ICE TLS is not standard anyway). Also, you typically have less TURN servers than media servers, so it is easier to have them allowed by IP on the firewalls. In our case for example, our IPs of the media server pool are dinamic, so we must use TURN server IPs instead. I will add notes for the other comments as suggested