Change:
1. WebRTC intentionally does not specify a signaling transport protocol <del> at application level, while RTCWEB standardized the signalling </del> <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 <del> allowed for implementing a wide range of services.  However, those services are typically standalone silos which don't require </del> <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 <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> <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> <del> While some standard signalling protocols are available that can be </del> <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 <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> <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> <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> <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 <del> ingest method which is: </del> <ins> media ingestion method which is: </ins> Easy to implement, As easy to use as current RTMP URIs. <del> Fully compliant with Webrtc and RTCWEB specs. </del> <ins> Fully compliant with WebRTC and RTCWEB specs. </ins> <del> Allow for both ingest in traditional media platforms for extension and ingest in webrtc end-to-end platform for lowest possible latency. </del> <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 <del> services to support webrtc. </del> <ins> services to support WebRTC. </ins> Usable both in web browsers and in native encoders.

Discussion:
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.