Draft: draft-murillo-whip

Commentary: Authtentication , bearear , proposse , detailled , endpoings , adption , traditionnal . 
 Thank you very much !
While WebRTC has been very sucessful in a wide range of scenarios,
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.
While WebRTC has been very sucessful in a wide range of scenarios,
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.
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
is always present in traditionnal streaming to support e.g.  ABR, and
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
server-side transcoding.  Content protection and Privacy Enhancement
can be achieve with End-to-End Encryption, which preclude any server-
side media processing.
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
is always present in traditional streaming to support e.g.  ABR, and
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
server-side transcoding.  Content protection and Privacy Enhancement
can be achieve with End-to-End Encryption, which preclude any server-
side media processing.
This document proposes a simple HTTP based protocol that will allow
WebRTC endpoings to ingest content into streaming servics and/or CDNs
to fill this gap and facilitate deployment.
This document proposes a simple HTTP based protocol that will allow
WebRTC endpoints to ingest content into streaming servics and/or CDNs
to fill this gap and facilitate deployment.
This document proposse a simple protocol for supporting WebRTC as
ingest method which is: - Easy to implement, - As easy to use as
current RTMP URI.  - Fully compliant with Webrtc and RTCWEB specs.  -
Allow for both ingest in traditionnal media platforms for extention
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
native encoders.
This document proposes a simple protocol for supporting WebRTC as
ingest method which is: - Easy to implement, - As easy to use as
current RTMP URI.  - Fully compliant with Webrtc and RTCWEB specs.  -
Allow for both ingest in traditional media platforms for extention
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
native encoders.
Authtentication and authorization is supported by the Authorization
HTTP header with a bearear token as per RFC6750.
Authentication and authorization is supported by the Authorization
HTTP header with a bearer token as per RFC6750.