Change:
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.”

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