4.4. <del> The WHIP endpoint MAY return ICE server configuration URLs and </del>  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>  username: If the Link header field represents a TURN server, and credential-type is "password", then this attribute specifies the value should be used when that TURN server requests authorization. The default value if the attribute is not present is "password".  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>  It might be also possible to configure the STUN/TURN server URLs with long term credentials provided by either the broadcasting service or 4.5.  WHIP endpoints and resources MAY require the HTTP request to be authenticated using an HTTP Authorization header field with a Bearer token as specified in RFC6750 section 2.1.  WHIP clients MUST not configured to use a bearer token, the HTTP Authorization header field must not be sent in any request. <del> 4.6. </del>  Both Simulcast RFC8853 and Salable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent simulcast offer MUST create an answer according to the procedures RFC8853 section 5.3.2. <del> 4.7. </del>  In order to support future extensions to be defined for the WHIP protocol, a common procedure for registering and announcing the new In this theoretical case, the HTTP 201 response to the HTTP POST request would look like: <del> 5. </del>  HTTPS SHALL be used in order to preserve the WebRTC security model. <del> 6. </del>  The link relation type below has been registered by IANA per Section 4.2 of RFC8288. <del> 6.1. </del>  Relation Name: ice-server Reference: TBD <del> 7. </del>

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

4.4.  <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.  <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 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  <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 4.5. <ins> 5. </ins> WHIP endpoints and resources MAY require the HTTP request to be authenticated using an HTTP Authorization header field with a Bearer token as specified in RFC6750 section 2.1.  WHIP clients MUST not configured to use a bearer token, the HTTP Authorization header field must not be sent in any request.  <ins> 5.1. </ins> Both Simulcast RFC8853 and Salable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent simulcast offer MUST create an answer according to the procedures RFC8853 section 5.3.2.  <ins> 5.2. </ins> In order to support future extensions to be defined for the WHIP protocol, a common procedure for registering and announcing the new In this theoretical case, the HTTP 201 response to the HTTP POST request would look like:  <ins> 6. </ins> HTTPS SHALL be used in order to preserve the WebRTC security model.  <ins> 7. </ins> The link relation type below has been registered by IANA per Section 4.2 of RFC8288.  <ins> 7.1. </ins> Relation Name: ice-server Reference: TBD  <ins> 8. </ins>


SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections.  When a WHIP client sends an SDP offer, it SHOULD insert an SDP "setup" attribute with an "actpass" attribute value, as defined in RFC8842.  However, if the WHIP client only implements the DTLS client

Until now, I've been working under the assumption that WHIP is limited to two tracks (audio+video) belonging to a single stream. However, I'm now realising that there's nothing in the draft that says this is the case. Please clarify which of the following is correct: the client MUST offer at most one audio and one video track (possibly simulcast/SVC) belonging to a single stream; the server MUST return an error if there are more than two tracks; the client MAY offer more than two tracks; how to handle this case is out of scope for WHIP, but the server MAY return an error if there are more than two tracks and the client MUST retry with just two tracks; the client MAY offer multiple tracks in multiple streams, and the server MUST accept the multiple streams. My preference is for (1) or (2), but I can live with (3).
I had doubts regarding this, as I foresee that we will want to support multi tracks/streams in the near future (for multilanguage support for example) I would propose something like. I don't want to add the retry client logic to the client, as I think most of the times it would be better to inform the end user about the error and explicitly asking form confirmation before doing any change in the stream/track. Note that this could happen today if the server supports audio only and the whip client is sending audio and video. I think that it is better to fail than just force retrying automatically with audio only.

SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections. <ins> While this version of the specification only supports a single audio and video track, in order to ensure forward compatibility, if the number of audio and or video tracks or number streams is not supported by the WHIP Endpoint, it MUST reject the HTTP POST request with a 406 Not Acceptable error code. Furthermore, the WHIP Endpoint SHOULD NOT reject individual "m=" sections as per RFC8829 section 5.3.1 in case there is any error processing the "m=" section, but reject the HTTP POST request with a 406 Not Acceptable error code to prevent having partially successful WHIP sessions. </ins> When a WHIP client sends an SDP offer, it SHOULD insert an SDP "setup" attribute with an "actpass" attribute value, as defined in RFC8842.  However, if the WHIP client only implements the DTLS client


used for ICE restarts, it will contain a new ICE ufrag/pwd pair. Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. <del> If both Trickle ICE or ICE restarts are not supported by the WHIP resource, it MUST return a 405 Method Not Allowed response for any HTTP PATCH request.  If the WHIP resource supports either Trickle ICE or ICE restarts, but not both, it MUST return a 501 Not Implemented for the HTTP PATCH requests that are not supported. </del>  As the HTTP PATCH request sent by a WHIP client may be received out- of-order by the WHIP resource, the WHIP resource MUST generate a

As per discussion during IETF WISH meeting
thank you for the PR Adam! One further question, I think we should consistently use the return code and reason phrase styling across the document. what would be best? 200 OK 200 "OK" 200 (OK)

used for ICE restarts, it will contain a new ICE ufrag/pwd pair. Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource.  <ins> If the WHIP resource supports either Trickle ICE or ICE restarts, but not both, it MUST return a 405 (Not Implemented) for the HTTP PATCH requests that are not supported.  If the server does not support the PATCH method for any purpose, it returns a 501 (Not Implemented), as described in RFC7231 section 6.6.2. </ins> As the HTTP PATCH request sent by a WHIP client may be received out- of-order by the WHIP resource, the WHIP resource MUST generate a


specifications which may use this mechanism to configure the usage of STUN/TURN servers. <del> 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. </del> NOTE: Depending on the ICE Agent implementation, the WHIP client may need to call the setConfiguration method before calling the setLocalDespcription method with the local SDP offer in order to avoid having to perform an ICE restart for applying the updated STUN/ TURN server configuration on the next ICE gathering phase.  The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTIONS request processing and increase the processing required to

NAME could you take a look please?
The current text ignores the issue that (in the absence of OPTIONS) the offer must be sent before it is set as the local description, in order to avoid starting the ICE agent prematurely. I think we should consult an ICE specialist in order to understand what consequences that will have on connectivity.
There is already a note already covering that case. It is up to the WHIP client implementation to know which is its ICE implementation support regarding this case and choose to call setLocalDescription or not before updateConfiguration. The only case were a WHIP client is not tightly coupled with a ICE implementation is on browsers, and we already have checked that it works on all webrtc browsers.

specifications which may use this mechanism to configure the usage of STUN/TURN servers.  NOTE: Depending on the ICE Agent implementation, the WHIP client may need to call the setConfiguration method before calling the setLocalDespcription method with the local SDP offer in order to avoid having to perform an ICE restart for applying the updated STUN/ TURN server configuration on the next ICE gathering phase. <ins> 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.  However, this method is not NOT RECOMMENDED and if supported by the underlying WHIP Client's webrtc implementation, the WHIP Client SHOULD wait for the information to be returned by the WHIP Endpoint on the response of the HTTP POST request instead. </ins> The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTIONS request processing and increase the processing required to


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. <del> The response may optionally contain the new set of ICE candidates for the Media Server and the new entity-tag correspond to the new ICE session in an ETag response header field. </del>  If the ICE request cannot be satisfied by the WHIP resource, the resource MUST return an appropriate HTTP error code and MUST NOT

NAME ping?
“The response may optionally contain the new set of ICE candidates for the Media Server and the new entity-tag correspond to the new ICE session in an ETag response header field.” Is this really meant to indicate that the new ICE candidates AND the new entity-tag are optional? I would have expected that after an ICE restart a new entity-tag is required.
The optionally only applies to the first part of, will reword it.

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.  <ins> Also, the "200 OK" response for a sucesscull ICE restart MUST contain the new entity-tag corresponding to the new ICE session in an ETag response header field and MAY contain a new set of ICE candidates for the Media Server. </ins> If the ICE request cannot be satisfied by the WHIP resource, the resource MUST return an appropriate HTTP error code and MUST NOT


Once the ICE/DTLS session is set up, the media will flow unidirectionally from the encoder/media producer (WHIP client) to the broadcasting ingestion endpoint (Media Server).  In order to reduce <del> complexity, no SDP renegotiation is supported, so no tracks or streams can be added or removed once the initial SDP offer/answer over HTTP is completed. </del>  4. SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections as per RFC8858. <del> While this version of the specification only supports, at most, a single audio and video track in a single media stream. (therefore, all "m=" sections MUST contain an "msid" attribute with the same value as per [[!RFC8830]]), in order to ensure forward compatibility, if the number of audio and or video tracks or number streams is not supported by the WHIP Endpoint, it MUST reject the HTTP POST request with a "406 Not Acceptable" error response. </del>  Furthermore, the WHIP Endpoint SHOULD NOT reject individual "m=" sections as per RFC8829 section 5.3.1 in case there is any error

Looks good.
thank you Bernard!
from NAME Section 2 I do not see a definition of “track”. I think this is important to clarify. Section 4.2 “ While this version of the specification only supports a single audio and video track, in order to ensure forward compatibility, if the number of audio and or video tracks or number streams is not supported by the WHIP Endpoint, it MUST reject the HTTP POST request with a "406 Not Acceptable" error response.”
updated the PR to add MediaStream/MediaStreamTrack references

Once the ICE/DTLS session is set up, the media will flow unidirectionally from the encoder/media producer (WHIP client) to the broadcasting ingestion endpoint (Media Server).  In order to reduce  <ins> complexity, no SDP renegotiation is supported, so no "m=" sections can be added once the initial SDP offer/answer over HTTP is completed. </ins> 4. SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections as per RFC8858.  <ins> This version of the specification only supports, at most, a single audio and video MediaStreamTrack in a single MediaStream as defined in [[!RFC8830]] and therefore, all "m=" sections MUST contain an "msid" attribute with the same value.  However, it would be possible for future revisions of this spec to allow more than a single MediaStream or MediaStreamTrack of each media kind, so in order to ensure forward compatibility, if the number of audio and or video tracks or number streams is not supported by the WHIP Endpoint, it MUST reject the HTTP POST request with a "406 Not Acceptable" error response. </ins> Furthermore, the WHIP Endpoint SHOULD NOT reject individual "m=" sections as per RFC8829 section 5.3.1 in case there is any error


1. <del> While WebRTC has been very successful in a wide range of scenarios, its adoption in the broadcasting/streaming industry is lagging behind. </del> The IETF RTCWEB working group standardized JSEP (RFC8829), a mechanism used to control the setup, management, and teardown of a multimedia session.  It also describes how to negotiate media flows (SDP) RFC3264 as well as the formats for data sent over the wire (e.g., media types, codec parameters, and encryption).  WebRTC intentionally does not specify a signaling transport protocol at <del> application level.  This flexibility has allowed the implementation of a wide range of services.  However, those services are typically standalone silos which don't require interoperability with other services or leverage the existence of tools that can communicate with them. In the broadcasting/streaming world, the use of hardware encoders that make it very simple to plug in cables carrying raw media, encode it in-place, and push it to any streaming service or CDN ingest is already ubiquitous.  The adoption of a custom signaling transport protocol for each WebRTC service has hindered broader adoption as an </del>  ingestion protocol. <del> While some standard signaling protocols are available that can be integrated with WebRTC, like SIP RFC3261 or XMPP RFC6120, they are not designed to be used in broadcasting/streaming services, and there also is no sign of adoption in that industry.  RTSP RFC7826, which is based on RTP and may be the closest in terms of features to WebRTC, is not compatible with the SDP offer/answer model RFC3264. So, currently, there is no standard protocol designed for ingesting media into a streaming service using WebRTC and so content providers still rely heavily on protocols like RTMP for doing so.  Most of those protocols are not RTP based, requiring media protocol translation when doing egress via WebRTC.  Avoiding this media protocol translation is desirable as there is no functional parity between those protocols and WebRTC and it increases the implementation complexity at the media server side. Also, the media codecs used in those protocols tend to be limited and not negotiated, not always matching the media codes supported in WebRTC.  This requires transcoding on the ingest node, which introduces delay, degrades media quality and increases the processing workload required on the server side.  Server side transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with Simulcast RFC8853 and SVC codecs that are well supported by WebRTC clients.  In addition, WebRTC clients can adjust client-side encoding parameters based on RTCP feedback to maximize encoding quality. </del>  This document proposes a simple protocol for supporting WebRTC as media ingestion method which:

Looks good.
thank you Bernard!
From NAME Section 1 “ While WebRTC has been very successful in a wide range of scenarios, its adoption in the broadcasting/streaming industry is lagging behind.” [BA] I recently saw a survey indicating that WHIP is now the second most implemented ingestion protocol, second only to RTMP. So while this sentence may have been correct at one time, it seems out of date now. Can we delete this sentence? Also, overall Section 1 seems like it could be shortened considerably by highlighting the major points. Here is my suggestion: “ The IETF RTCWEB working group standardized JSEP ([RFC8829]), a mechanism used to control the setup, management, and teardown of a multimedia session. JSEP also describes how to negotiate media flows using the Offer/Answer Model with the Session Description Protocol (SDP) [RFC3264] as well as the formats for data sent over the wire (e.g., media types, codec parameters, and encryption). WebRTC intentionally does not specify a signaling transport protocol at application level. Unfortunately, the lack of a standardized signaling mechanism in WebRTC has been an obstacle to adoption as an ingestion protocol within the broadcast/streaming industry, where a streamlined production pipeline is taken for granted: plug in cables carrying raw media to hardware encoders, then push the encoded media to any streaming service or Content Delivery Network (CDN) ingest using an ingestion protocol. While WebRTC can be integrated with standard signaling protocols like SIP [RFC3261] or XMPP [RFC6120], they are not designed to be used in broadcasting/streaming services and there is no sign of adoption in that industry. RTSP [RFC7826], which is based on RTP, is not compatible with the SDP offer/answer model [RFC3264]. This document therefore proposes a simple protocol for supporting WebRTC as a media ingestion method which: Is easy to implement, Is as easy to use as popular IP-based broadcast protocols Is fully compliant with WebRTC and RTCWEB specs Allows for ingest both in traditional media platforms and in WebRTC end-to-end platforms with the lowest possible latency. Lowers the requirements on both hardware encoders and broadcasting services to support WebRTC. Is usable both in web browsers and in native encoders.”

1.  The IETF RTCWEB working group standardized JSEP (RFC8829), a mechanism used to control the setup, management, and teardown of a multimedia session.  It also describes how to negotiate media flows (SDP) RFC3264 as well as the formats for data sent over the wire (e.g., media types, codec parameters, and encryption).  WebRTC intentionally does not specify a signaling transport protocol at  <ins> application level. Unfortunately, the lack of a standardized signaling mechanism in WebRTC has been an obstacle to adoption as an ingestion protocol within the broadcast/streaming industry, where a streamlined production pipeline is taken for granted: plug in cables carrying raw media to hardware encoders, then push the encoded media to any streaming service or Content Delivery Network (CDN) ingest using an </ins> ingestion protocol.  <ins> While WebRTC can be integrated with standard signaling protocols like SIP RFC3261 or XMPP RFC6120, they are not designed to be used in broadcasting/streaming services, and there also is no sign of adoption in that industry.  RTSP RFC7826, which is based on RTP, is not compatible with the SDP offer/answer model RFC3264. </ins> This document proposes a simple protocol for supporting WebRTC as media ingestion method which: