Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol

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

Hi Tim,

I see the merits for an uri-based signal-less and sdp-less setup for 
webrtc, specially for p2, in which you could even use datachannel as 
control channel for adding and removing tracks later on. However, that 
is far beyond the scope of my current draft.

You say that this may not go far enough, and I could agree to that, but 
relying on current SDP O/A mechanism, HTTP and webrtc specs allows to 
have simple spec that we can have ready and working really fast. I agree 
to add constrains or force usage of certain optional features defined in 
other specs to simplify the implementation complexity on both servers 
and clients, but if we plan to redefine SDP I am afraid that we will get 
into a rabbit hole that will keep us discussing for months/years.

As I said, I see the benefits of it, but I would prefer to leave it out 
of scope of current WHIP draft spec and if anyone is interested in 
leading the work, start an independent draft for that. I will be willing 
to collaborate anyway.

Best regards
Sergio

On 29/10/2020 12:07, T H Panton wrote:
> My feedback:
>
> 1) this is a good idea - we need something like this. Full webRTC O/A 
> is too complex for simple ingestion usecases.
> 2) A URI is an excellent hook to hang this on.
> 3) I don't think it goes far enough.
>
> Almost all of the offer/answer content is redundant, because most of 
> it is _known_ by both sides already.
> The ingestion services typically specify what 
> codecs/bitrates/framerates they will accept.
> They don't output any media.
>
> I claim we can simplify the O/A to something that looks more like 
> RTSP's SDP or even simpler.
>
> - So I support this, but would want to discuss simplification.
>
> Tim.
>
>> On 28 Oct 2020, at 20:10, Ben Campbell <[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://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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch