Change:
value should be used when that TURN server requests authorization. The default value if the attribute is not present is "password". <ins> NOTE: The naming of both the "rel" attribute value of "ice-server" and the target attributes follows the one used on the W3C WebRTC recomendation ?W3C.REC-webrtc-20210126 RTCConfiguration dictionary in section 4.2.1. "rel" attribute value of "ice-server" is not prepended with the "urn:ietf:params:whip:" so it can be reused by other specifications which may use this mechanishm to configure the usage of STUN/TURN servers. </ins> There are some WebRTC implementations that do not support updating <del> 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. </del> <ins> the STUN/TURN server configuration after the local offer has been created as specified in RFC8829 section 4.1.18.  In order to support these clients, the WHIP endpoint MAY also include the STUN/TURN server configuration on the responses to OPTIONS request sent to the WHIP endpoint URL before the POST request is sent. The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTION request processing and increase the processing required to handle that request.  In order to prevent this, the WHIP Endpoint SHOULD NOT return the STUN/TURN server configuration if the OPTION request is a preflight request for CORS, that is, if The OPTION request does not contain an Access-Control-Request-Method with "POST" value and the the Access-Control-Request-Headers HTTP header does not contain the "Link" value. </ins> It might be also possible to configure the STUN/TURN server URLs with long term credentials provided by either the broadcasting service or

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