Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol

From: Ben Campbell <[email-masked]>
Date: Wed, 28 Oct 2020 15:10:04 -0500

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 <[email-masked]> 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://tools.ietf.org/html/draft-murillo-whip-00>
> https://github.com/murillo128/webrtc-http-ingest-protocol/ <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://www.meetecho.com/blog/whip-janus/>
> https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7 <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 <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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Thu, 29 Oct 2020 11:14:05 +0800

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 <[email-masked]> wrote:

> 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/
>
>
>    - https://www.meetecho.com/blog/whip-janus/
>    -
>    https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7
>
>
>    -
>    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.
>
>

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

   -

---

From: T H Panton <[email-masked]>
Date: Thu, 29 Oct 2020 11:07:41 +0000

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 <[email-masked]> wrote:
> 
> Hi Everyone,
> 
>> On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi all!
>> 
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 29 Oct 2020 13:02:48 +0100

In addition to the use cases mentioned, having a simple standard 
"configure this connection" protocol would make setting up a server for 
testing (the parts that can't be done by a browser talking to itself) a 
lot simpler.

Harald

On 10/28/20 9:10 PM, Ben Campbell wrote:
>> On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo 
>> <[email-masked] 
>> <mailto:[email-masked]>> 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.
>>
>> 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/
>>
>>
>>   * https://www.meetecho.com/blog/whip-janus/
>>   * https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7
>>
>>
>>   * 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.
>>
>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 29 Oct 2020 14:24:19 +0100

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.
> The ingestion services typically specify what 
> codecs/bitrates/framerates they will accept.
>> On 28 Oct 2020, at 20:10, Ben Campbell <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Everyone,
>>
>>> 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.
>>>

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 29 Oct 2020 14:56:11 +0100

I personally think the currently proposed approach is fine and simple
enough. Going for further simplification may actually complicate things,
paradoxically: if we assume some parameters are known already, it means
potentially crafting and munging SDPs on the client side if the
existing APIs don't allow for such flexibility, which in case of
browsers may be suboptimal (not to mention SDP munging may actually not
even be possible sooner or later). The alternative would be letting the
server offer and the client answer, but that means you can't do it with
a single HTTP request as WHIP does now.

The only feedback I have is adding the ability to expose a further URL
(e.g., something you can send an HTTP DELETE to) to interrupt the
ingestion, as I think just relying on ICE and DTLS may not be reliable
or quick enough, not to mention the fact that there would be no way to
distinguish between a user dropping their connection, and the user
actually meaning to close the connection in the first place.

Lorenzo

On Thu, 29 Oct 2020 14:24:19 +0100
Sergio Garcia Murillo <[email-masked]> wrote:

> 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
> 
> > 1) this is a good idea - we need something like this. Full webRTC
> > O/A is too complex for simple ingestion usecases.
> >>> 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
> >>> 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:
> >>>
> >>>   *
> >>>   *
> >>> We also plan to have an interop session on the next IETF
> >>> hackhaton, that will allow to check the interoperability between
> >>> different WebRTC implementations.
> >>>
> >>>

-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero