Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol

[Adam Roach <[e-mail]>]

Having read through the proposal and watched the corresponding segment 
of the DISPATCH meeting from two weeks ago, I think that having 
something like this standardized would be very useful, both for the 
handful of broadcasting tools that exist as well as for the various 
WebRTC broadcast networks that are being deployed.

So I definitely think we should pursue this work in the IETF.

It's a little less clear to me whether we want to slot this into 
something like MMUSIC or to create a short-lived working group. I'm 
leaning towards the second, for a couple of reasons. First, I found 
Ted's comments at the DISPATCH meeting to be kind of illuminating as far 
as the kinds of additional work that might be necessary (and I have my 
own list of things that might need some refinement, like negotiation of 
authentication mechanisms); and that nudges the effort into a "maybe a 
little larger than just one work item in a long-standing working group." 
More importantly, this work straddles the real-time media and web 
disciplines, and I'd like to make sure we have people from the latter 
group putting eyes on it. I seriously doubt we can get HTTP experts 
showing up at MMUSIC, but there's at least a fair chance that we might 
get them interested in a lower-volume mailing list such as a dedicated 
WHIP WG.

I think this mirrors, for the most part, the tentative conclusion that 
came out of the DISPATCH discussion earlier this month. If we decide to 
take this path of creating a short-lived WG, I'm happy to help craft a 
charter and plan to be actively involved in the technical work.

/a


On 10/28/2020 3:10 PM, Ben Campbell 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://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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch