Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol

[Alexandre GOUAILLARD <[e-mail]>]

Dear all,

Just to clarify the scope.

WHIP is a very light weight **signalling** (or control) protocol that acts
as the missing reference companion protocol to webrtc in the specific
(simplified) use case of webrtc ingest into platforms. The media part, the
network part, and the media encryption are handled by webrtc itself. The
security of the signalling protocol is handled by HTTPS.

In that regard, conceptually, it is very close to what RTSP(s) 2.0 was to
RTP, and it could make sense, now that the RTCWEB group is closed, to let
either the AVTCORE or the MMUSIC group adopt it.

Regards,





On Thu, Oct 29, 2020 at 4:10 AM Ben Campbell <[e-mail]> wrote:

> Hi Everyone,
>
> Did anyone have feedback or other thoughts on Sergio’s proposal?
>
> Thanks!
>
> Ben.
>
> On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo <
> [e-mail]> wrote:
>
> Hi all!
>
>
> While WebRTC has been very successful in a wide range of scenarios, its
> adaption 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.
>
> These protocols are much older than WebRTC and lack by default some
> important security and resilience features provided by WebRTC with minimal
> delay.
>
> 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, 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.
>
> We have been working on a proposal for a simple HTTP based protocol that
> will allow WebRTC endpoints to ingest content into streaming services
> and/or CDNs to fill this gap and facilitate deployment:
>
>    - https://tools.ietf.org/html/draft-murillo-whip-00
>    - https://github.com/murillo128/webrtc-http-ingest-protocol/
>
>
> We have already implemented it on Janus and Medooze media servers:
>
>    - https://www.meetecho.com/blog/whip-janus/
>    -
>    https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7
>
>
> And added support into a WebRTC version of OBS studio:
>
>    -
>    https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2
>
>
> We also plan to have an interop session on the next IETF hackhaton, that
> will allow to check the interoperability between different WebRTC
> implementations.
>
>
> What would be the best way of moving this forward? Obviously, any feedback
> will be very welcome.
>
>
> Best regards
>
> Sergio
>
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>


-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -