Original text:
1. WebRTC intentionally does not specify a signaling transport protocol <del> at application level, while RTCWEB standardized the signalling </del>  protocol itself (JSEP, SDP O/A) and everything that was going over the wire (media, codec, encryption, ...).  This flexibility has <del> allowed for implementing a wide range of services.  However, those services are typically standalone silos which don't require </del>  interoperability with other services or leverage the existence of tools that can communicate with them. In the broadcasting/streaming world, the usage of hardware encoders <del> that would make it very simple to plug in (SDI) cables carrying raw media, encoding it in place, and pushing it to any streaming service or CDN ingest is ubiquitous.  Having to implement a custom signalling transport protocol for each different webrtc services has hindered adoption. </del>  <del> While some standard signalling protocols are available that can be </del>  integrated with WebRTC, like SIP or XMPP, they are not designed to be used in broadcasting/streaming services, and there also is no sign of <del> adoption in that industry.  RTSP, which is based on RTP and maybe the closest in terms of features to webrtc, is not compatible with WebRTC SDP offer/answer model. </del>  <del> In the specific case of ingest into a platform, some assumption can be made about the server-side which simplifies the webrtc compliance burden, as detailed in webrtc-gateway document I-D.draft-alvestrand- rtcweb-gateways. </del>  This document proposes a simple protocol for supporting WebRTC as <del> ingest method which is: </del>  Easy to implement, As easy to use as current RTMP URIs. <del> Fully compliant with Webrtc and RTCWEB specs. </del>  <del> Allow for both ingest in traditional media platforms for extension and ingest in webrtc end-to-end platform for lowest possible latency. </del>  Lowers the requirements on both hardware encoders and broadcasting <del> services to support webrtc. </del>  Usable both in web browsers and in native encoders. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <del> WHIP client: WebRTC Media encoder or producer that acts as client on the WHIP protocol and encodes and delivers the media to a remote media server. </del>  WHIP endpoint: Ingest server receiving the initial WHIP request. WHIP endpoint URL: URL of the WHIP endpoint that will create the <del> WHIP resource </del>  <del> Media Server: WebRTC media server that establishes the media session with the WHIP client and receives the media produced by it. </del>  WHIP resource: Allocated resource by the WHIP endpoint for an <del> ongoing ingest session that the WHIP client can send request for </del>  altering the session (ICE operations or termination, for example). WHIP resource URL: URL allocated to a specific media session by <del> the WHIP endpoint which can be used to perform operations such </del>  terminating the session or ICE restarts. 3. The WebRTC-HTTP ingest protocol (WHIP) uses an HTTP POST request to perform a single shot SDP offer/answer so an ICE/DTLS session can be <del> established between the encoder/media producer and the broadcasting ingestion endpoint. </del>  Once the ICE/DTLS session is set up, the media will flow <del> unidirectionally from the encoder/media producer to the broadcasting ingestion endpoint.  In order to reduce complexity, no SDP renegotiation is supported, so no tracks or streams can be added or removed once the initial SDP O/A over HTTP is completed. </del>  4. to the WHIP endpoint configured URL. The HTTP POST request will have a content type of application/sdp and <del> contain the SDP offer as body.  The WHIP endpoint will generate an SDP answer and return it on a 201 Accepted response with content type of application/sdp and the SDP answer as body and a Location header pointing to the newly created resource. </del>  <del> SDP offer SHOULD use the sendonly attribute and the SDP answer MUST use the recvonly attribute. </del>  <del> Once a session is setup ICE consent freshness RFC7675 will be used to detect abrupt disconnection and DTLS teardown for session termination by either side. </del>  To explicitly terminate the session, the WHIP client MUST perform an <del> HTTP DELETE request to the resource url returned on the Location </del>  header of the initial HTTP POST.  Upon receiving the HTTP DELETE request, the WHIP resource will be removed and the resources freed on the media server, terminating the ICE and DTLS sessions. NAT, the WHIP media server SHOULD be publicly accessible. The initial offer by the WHIP client MAY be sent after the full ICE <del> gathering is complete containing the full list of ICE candidates, or only contain local candidates or even an empty list of candidates. </del>  The WHIP endpoint SDP answer SHALL contain the full list of ICE candidates publicly accessible of the media server.  The media server The WHIP client MAY perform trickle ICE or an ICE restarts RFC8863 by sending a HTTP PATCH request to the WHIP resource URL with a body <del> containing a SDP fragment with mime type "application/trickle-ice- sdpfrag" as specified in RFC8840 with the new ice candidate or ice ufrag/pwd for ice restarts.  A WHIP resource MAY not support either trickle ICE (i.e.  ICE lite media servers) or ICE restart, and it MUST return a 405 Method Not Allowed for any HTTP PATCH request. </del>  A WHIP client receiving a 405 response for an HTTP PATCH request SHALL not send further request for ICE trickle or restart.  If the WHIP client gathers additional candidates (via STUN/TURN) after the <del> SDP offer is sent, it MUST send STUN request to the ICE candidates received from the media server as per RFC8838 regardless if the HTTP PATCH is supported by either the WHIP client or the WHIP resource. </del>  4.2. WHIP endpoints and media servers MAY not be colocated on the same server so it is possible to load balance incoming requests to different media servers.  WHIP clients SHALL support HTTP redirection <del> via 307 Temporary Redirect response code. </del>  <del> In case of high load, the WHIP endpoints may return a 503 (Service </del>  Unavailable) status code indicating that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. Configuration of the TURN or STUN servers used by the WHIP client is out of the scope of this document. <del> It is RECOMMENDED that broadcasting server provides an HTTP interface for provisioning the TUNR/STUN servers url and short term credentiasl as in I-D.draft-uberti-behave-turn-rest-00.  Note that the authentication information or the url of this API are not related to the WHIP enpoint URLs or authentication. </del>  <del> It could also be possilble to configure the STUN/TURN server URLS and long term credentials provided by the either broadcasting service or an external TURN provider. </del>  4.5. <del> Authentication and authorization is supported by the Authorization HTTP header with a bearer token as per RFC6750. </del>  4.6. Both simulcast and scalable video coding (including K-SVC modes) MAY <del> be supported by both media servers and WHIP clients and negotiated in the SDP O/A. </del>  If the client supports simulcast and wants to enable it for publishing, it MUST negotiate the support in the SDP offer according extensions is defined. Protocol extensions supported by the WHIP server MUST be advertised <del> to the WHIP client on the 201 created response to initial HTTP POST request to the WHIP enpoint by inserting one Link header for each extension with the extension "rel" type attribute and the uri for the HTTP resource that will be available for receiving request related to that extension. </del>  <del> Protocol extensions are optionasl for bot WHIP clients and servers. </del>  WHIP clients MUST ignore any Link attribute with an unknown "rel" attribute value and WHIP servers MUST not require the usage of any of the extensions. For example, taking a potential extension of server to client communication using server sent events as specified in https://html.spec.whatwg.org/multipage/server-sent- <del> events.html#server-sent-events, the url for connecting to the server </del>  side event resource for the published stream will be returned in the <del> initial HTTP "201 Created" response with a "Link" header an a "rel" </del>  attribute of "urn:ietf:params:whip:server-sent-events". The HTTP 201 response to the HTTP POST request would look like:

Reviewer comments:
I gave the spec a good read through and would like to propose some minor language edits as my first contribution. Most of these are straight forward such as: WebRTC not webrtc URI not uri signaling not signalling offer/answer not O/A some grammatical changes There is one somewhat significant correction here in that the header on the example WHIP endpoint reply pointed at the RFC for the extension. I believe this is incorrect and the intent is that this points at a WHIP resource. I have updated the example as such.

Revised text:
1. WebRTC intentionally does not specify a signaling transport protocol  <ins> at application level, while RTCWEB standardized the signaling </ins> protocol itself (JSEP, SDP O/A) and everything that was going over the wire (media, codec, encryption, ...).  This flexibility has  <ins> allowed the implementation of a wide range of services.  However, those services are typically standalone silos which don't require </ins> interoperability with other services or leverage the existence of tools that can communicate with them. In the broadcasting/streaming world, the usage of hardware encoders  <ins> that make it very simple to plug in (SDI) cables carrying raw media, encode it in place, and push it to any streaming service or CDN ingest is already ubiquitous.  It is the adoption of a custom signaling transport protocol for each WebRTC service has hindered broader adoption as an ingestion protocol. </ins>  <ins> While some standard signaling protocols are available that can be </ins> integrated with WebRTC, like SIP or XMPP, they are not designed to be used in broadcasting/streaming services, and there also is no sign of  <ins> adoption in that industry.  RTSP, which is based on RTP and may be the closest in terms of features to WebRTC, is not compatible with the WebRTC SDP offer/answer model. </ins>  <ins> In the specific case of media ingestion into a streaming service, some assumptions can be made about the server-side which simplifies the WebRTC compliance burden, as detailed in webrtc-gateway document I-D.draft-alvestrand-rtcweb-gateways. </ins> This document proposes a simple protocol for supporting WebRTC as  <ins> media ingestion method which is: </ins> Easy to implement, As easy to use as current RTMP URIs.  <ins> Fully compliant with WebRTC and RTCWEB specs. </ins>  <ins> Allows for both ingest in traditional media platforms and ingest in WebRTC end-to-end platforms with the lowest possible latency. </ins> Lowers the requirements on both hardware encoders and broadcasting  <ins> services to support WebRTC. </ins> Usable both in web browsers and in native encoders. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.  <ins> WHIP client: WebRTC media encoder or producer that acts as a client of the WHIP protocol by encoding and delivering the media to a remote media server. </ins> WHIP endpoint: Ingest server receiving the initial WHIP request. WHIP endpoint URL: URL of the WHIP endpoint that will create the  <ins> WHIP resource. </ins>  <ins> Media Server: WebRTC media server or consumer that establishes the media session with the WHIP client and receives the media produced by it. </ins> WHIP resource: Allocated resource by the WHIP endpoint for an  <ins> ongoing ingest session that the WHIP client can send requests for </ins> altering the session (ICE operations or termination, for example). WHIP resource URL: URL allocated to a specific media session by  <ins> the WHIP endpoint which can be used to perform operations such as </ins> terminating the session or ICE restarts. 3. The WebRTC-HTTP ingest protocol (WHIP) uses an HTTP POST request to perform a single shot SDP offer/answer so an ICE/DTLS session can be  <ins> established between the encoder/media producer (WHIP client) and the broadcasting ingestion endpoint (media server). </ins> Once the ICE/DTLS session is set up, the media will flow  <ins> unidirectionally from the encoder/media producer (WHIP client) to the broadcasting ingestion endpoint (media server).  In order to reduce 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. </ins> 4. to the WHIP endpoint configured URL. The HTTP POST request will have a content type of application/sdp and  <ins> contain the SDP offer as the body.  The WHIP endpoint will generate an SDP answer and return a 201 Accepted response with a content type of application/sdp and the SDP answer as the body and a Location header pointing to the newly created resource. </ins>  <ins> The SDP offer SHOULD use the sendonly attribute and the SDP answer MUST use the recvonly attribute. </ins>  <ins> Once a session is setup, ICE consent freshness RFC7675 will be used to detect abrupt disconnection and DTLS teardown for session termination by either side. </ins> To explicitly terminate the session, the WHIP client MUST perform an  <ins> HTTP DELETE request to the resource URL returned in the Location </ins> header of the initial HTTP POST.  Upon receiving the HTTP DELETE request, the WHIP resource will be removed and the resources freed on the media server, terminating the ICE and DTLS sessions. NAT, the WHIP media server SHOULD be publicly accessible. The initial offer by the WHIP client MAY be sent after the full ICE  <ins> gathering is complete with the full list of ICE candidates, or only contain local candidates or even an empty list of candidates. </ins> The WHIP endpoint SDP answer SHALL contain the full list of ICE candidates publicly accessible of the media server.  The media server The WHIP client MAY perform trickle ICE or an ICE restarts RFC8863 by sending a HTTP PATCH request to the WHIP resource URL with a body  <ins> containing a SDP fragment with MIME type "application/trickle-ice- sdpfrag" as specified in RFC8840 with the new ICE candidate or ICE ufrag/pwd for ICE restarts.  A WHIP resource MAY not support trickle ICE (i.e.  ICE lite media servers) nor ICE restart, and it MUST return a 405 Method Not Allowed for any HTTP PATCH request. </ins> A WHIP client receiving a 405 response for an HTTP PATCH request SHALL not send further request for ICE trickle or restart.  If the WHIP client gathers additional candidates (via STUN/TURN) after the  <ins> SDP offer is sent, it MUST send a STUN request to the ICE candidates received from the media server as per RFC8838 regardless of the HTTP PATCH supported by either the WHIP client or the WHIP resource. </ins> 4.2. WHIP endpoints and media servers MAY not be colocated on the same server so it is possible to load balance incoming requests to different media servers.  WHIP clients SHALL support HTTP redirection  <ins> via the 307 Temporary Redirect response code. </ins>  <ins> In case of high load, the WHIP endpoints MAY return a 503 (Service </ins> Unavailable) status code indicating that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. Configuration of the TURN or STUN servers used by the WHIP client is out of the scope of this document.  <ins> It is RECOMMENDED that the broadcasting server provides an HTTP interface for provisioning the STUN/TURN servers' URLs and short term credentials as in I-D.draft-uberti-behave-turn-rest-00.  Note that neither the authentication information nor the URLs of the STUN/TURN servers are related to the WHIP endpoint. </ins>  <ins> It is also possible to configure the STUN/TURN server URLs with long term credentials provided by either the broadcasting service or an external TURN provider. </ins> 4.5.  <ins> Authentication and authorization MAY be supported on the WHIP endpoint and the WHIP resource by providing the Authorization HTTP header with a bearer token as per RFC6750. </ins> 4.6. Both simulcast and scalable video coding (including K-SVC modes) MAY  <ins> be supported by both the media servers and WHIP clients through negotiation in the SDP offer/answer. </ins> If the client supports simulcast and wants to enable it for publishing, it MUST negotiate the support in the SDP offer according extensions is defined. Protocol extensions supported by the WHIP server MUST be advertised  <ins> to the WHIP client on the 201 Created response to the initial HTTP POST request sent to the WHIP endpoint.  The WHIP endpoint MUST return one Link header for each extension with the extension "rel" type attribute and the URI for the HTTP resource that will be available for receiving requests related to that extension. </ins>  <ins> Protocol extensions are optional for both WHIP clients and servers. </ins> WHIP clients MUST ignore any Link attribute with an unknown "rel" attribute value and WHIP servers MUST not require the usage of any of the extensions. For example, taking a potential extension of server to client communication using server sent events as specified in https://html.spec.whatwg.org/multipage/server-sent-  <ins> events.html#server-sent-events, the URL for connecting to the server </ins> side event resource for the published stream will be returned in the  <ins> initial HTTP "201 Created" response with a "Link" header and a "rel" </ins> attribute of "urn:ietf:params:whip:server-sent-events". The HTTP 201 response to the HTTP POST request would look like: