Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol

[Lorenzo Miniero <[e-mail]>]

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 <[e-mail]> wrote:

> 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  
> 
> 



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