Draft: draft-ietf-wish-whip

Commentary: Looks good . 
 thank you  ! 
 From 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  ( [ RFC8829 ] ) , a mechanism used to control the setup , management , and teardown of a multimedia session .  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 . ”
While WebRTC has been very successful in a wide range of scenarios,
its adoption in the broadcasting/streaming industry is lagging
behind.
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
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.  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
ingestion protocol.
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.
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 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.