Original text:
Abstract While WebRTC has been very sucessful in a wide range of scenarios, <del> its adption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it. </del>  These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality.  This transcoding step <del> is always present in traditionnal streaming to support e.g.  ABR, and </del>  comes at no cost.  However webrtc implements client-side ABR, also called Network-Aware Encoding by e.g.  Huavision, by means of simulcast and SVC codecs, which otherwise alleviate the need for side media processing. This document proposes a simple HTTP based protocol that will allow <del> WebRTC endpoings to ingest content into streaming servics and/or CDNs </del>  to fill this gap and facilitate deployment. 1. In the specific case of ingest into a platform, some assumption can be made about the server-side which simplifies the webrtc compliance <del> burden, as detailled in webrtc-gateway document. </del>  https://tools.ietf.org/html/draft-ietf-rtcweb-gateways-02 <del> This document proposse a simple protocol for supporting WebRTC as </del>  ingest method which is: - Easy to implement, - As easy to use as current RTMP URI.  - Fully compliant with Webrtc and RTCWEB specs.  - <del> Allow for both ingest in traditionnal media platforms for extention </del>  and ingest in webrtc end-to-end platform for lowest possible latency. - Lowers the requirements on both hardware encoders and broadcasting services to support webrtc.  - Usable both in web browsers and in 4.4. <del> Authtentication and authorization is supported by the Authorization HTTP header with a bearear token as per RFC6750. </del>  4.5.

Reviewer comments:
Authtentication, bearear, proposse, detailled, endpoings, adption, traditionnal.
Thank you very much!

Revised text:
Abstract While WebRTC has been very sucessful in a wide range of scenarios,  <ins> its adoption in the broadcasting/streaming industry is lagging behind.  Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it. </ins> These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality.  This transcoding step  <ins> is always present in traditional streaming to support e.g.  ABR, and </ins> comes at no cost.  However webrtc implements client-side ABR, also called Network-Aware Encoding by e.g.  Huavision, by means of simulcast and SVC codecs, which otherwise alleviate the need for side media processing. This document proposes a simple HTTP based protocol that will allow  <ins> WebRTC endpoints to ingest content into streaming servics and/or CDNs </ins> to fill this gap and facilitate deployment. 1. In the specific case of ingest into a platform, some assumption can be made about the server-side which simplifies the webrtc compliance  <ins> burden, as detailed in webrtc-gateway document. </ins> https://tools.ietf.org/html/draft-ietf-rtcweb-gateways-02  <ins> This document proposes a simple protocol for supporting WebRTC as </ins> ingest method which is: - Easy to implement, - As easy to use as current RTMP URI.  - Fully compliant with Webrtc and RTCWEB specs.  -  <ins> Allow for both ingest in traditional media platforms for extention </ins> and ingest in webrtc end-to-end platform for lowest possible latency. - Lowers the requirements on both hardware encoders and broadcasting services to support webrtc.  - Usable both in web browsers and in 4.4.  <ins> Authentication and authorization is supported by the Authorization HTTP header with a bearer token as per RFC6750. </ins> 4.5.