Draft: draft-ietf-wish-whip

Commentary:  ? 
 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  URIs have to be enclosed by < and . Third , I think the " ice - server " value is misleading . An ICE server is not the same thing as a STUN / TURN server . You do n'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 
 Wo n'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
The WHIP endpoint MAY return ICE server configuration URLs and
credentials usable by the client in the "201 Created" response to the
HTTP POST request to the WHIP endpoint URL.
The WHIP endpoint MAY return STUN/TURN server configuration URLs and
credentials usable by the client in the "201 Created" response to the
HTTP POST request to the WHIP endpoint URL.
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.
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.
There are some WebRTC implementations that do not support updating
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.