Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol

[Sergio Garcia Murillo <[e-mail]>]

Hi Glen,

We are already participating in the MOPS, but I don't think it is the 
best place to progress the proposal, from the MOPS charter:

"The scope is media and media protocols’ interactions with the network, 
but not the technologies of control protocols or media formats."

However, we were thinking in using it in the future hackathon for 
testing webrtc as currently there is no other easy way to test webrtc 
across a different set of implementations without ad-hoc integrations.

Regarding SRT and RIST, none of them work on a web browser as an ingest 
point nor they allow easily to be translated to webrtc to enable lowest 
delay on distribution via webrtc.

Best regards
Sergio


On 28/10/2020 21:15, Deen, Glenn (NBCUniversal) wrote:
>
> It may make sense to cross post this to the MOPS mailing list.
>
> I’ll point out that SRT and RIST are two examples of protocols used 
> professionally to transport content during acquisition.
>
> Also, there has been discussion in MOPS about setting up a future 
> side-by-side set of transport tests and measurements to understand the 
> behaviors of the different transports – perhaps at a future IETF 
> hackathon when everyone can work together in the same room.
>
> -glenn
>
> On 10/28/20, 1:10 PM, "dispatch on behalf of Ben Campbell" 
> <[e-mail] <mailto:[e-mail]> on 
> behalf of [e-mail] <mailto:[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]
>     <mailto:[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://urldefense.com/v3/__https:/tools.ietf.org/html/draft-murillo-whip-00__;!!PIZeeW5wscynRQ!9L_DNSdPeeoXLgUWPHxltW0pZODhGty6iE_32wPjkm_35t7efqRa8LgvUVLJq4K6$>
>
>     ·https://github.com/murillo128/webrtc-http-ingest-protocol/
>     <https://urldefense.com/v3/__https:/github.com/murillo128/webrtc-http-ingest-protocol/__;!!PIZeeW5wscynRQ!9L_DNSdPeeoXLgUWPHxltW0pZODhGty6iE_32wPjkm_35t7efqRa8LgvUV7BZxYO$>
>
>     We have already implemented it on Janus and Medooze media servers:
>
>     ·https://www.meetecho.com/blog/whip-janus/
>     <https://urldefense.com/v3/__https:/www.meetecho.com/blog/whip-janus/__;!!PIZeeW5wscynRQ!9L_DNSdPeeoXLgUWPHxltW0pZODhGty6iE_32wPjkm_35t7efqRa8LgvUe7b_AWx$>
>
>     ·https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7
>     <https://urldefense.com/v3/__https:/medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7__;!!PIZeeW5wscynRQ!9L_DNSdPeeoXLgUWPHxltW0pZODhGty6iE_32wPjkm_35t7efqRa8LgvUcYIm2hL$>
>
>     And added support into a WebRTC version of OBS studio:
>
>     ·https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2
>     <https://urldefense.com/v3/__https:/github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2__;!!PIZeeW5wscynRQ!9L_DNSdPeeoXLgUWPHxltW0pZODhGty6iE_32wPjkm_35t7efqRa8LgvUbByufEt$>
>
>     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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dispatch
>     <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dispatch__;!!PIZeeW5wscynRQ!9L_DNSdPeeoXLgUWPHxltW0pZODhGty6iE_32wPjkm_35t7efqRa8LgvUSfLxU4X$>
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch