W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2018

Re: Use cases / requirements for raw data access functions

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 21 May 2018 11:35:22 -0700
Message-ID: <CAJrXDUHGE0vuw5K2nQVW856SiBi5M44WKmkYiUe1n-8REtRn6w@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: public-webrtc@w3.org
On Sun, May 20, 2018 at 9:08 PM Harald Alvestrand <harald@alvestrand.no>

> On 05/18/2018 11:33 PM, Peter Thatcher wrote:
> > By the way, this is my use case: as a web/mobile developer, I want to
> > send media over QUIC for my own replacement for RTP.  QUIC isn't the
> > replacement for RTP, but my own protocol on top of QUIC (or SCTP, or
> > any data channel) is the replacement for RTP.    Luckily, this is
> > "free" as soon as you add QUIC data channels and split the RtpSender
> > into encoder and transport.  That's all I need.
> >
> Peter,
> since I'm asking this of others:
> can you please expand this into an use case - describe a function or
> application that is possible / easy when you have that functionality
> available, and is impossible / hard to do today?

I have a few:

- Terminating media (audio, video, data) on a server is a pain in the neck
with DTLS/RTP/RTCP/SCTP.   I would like that to be much easier.  Sending a
serialized frame object (say, CBOR or protobuf) over a QUIC stream is way
easier to terminate.
- Including real-time data that's synchronized with audio and data, or
including metadata about a particular audio for video frame is much easier
if I can just attach it to a serialized frame object as mentioned above.
- Taking more directly control over stream control signaling (mute state,
key frame requests, end-of-stream), etc is much easier if the control plane
is controlled by the application and can be integrated with the flow of
media, unlike today with RTCP (not under control of app) or data channels
(not integrated with flow of media).
- e2ee without the complexities of double SRTP.

All of these have been brought up as use cases already by developers in
responses to Sergio's survey

More generally, RTP is needlessly complex.  It's hard to add things, it's
hard to change things, it's hard to debug things, and it's hard to
understand things.  So in a sense, my use case is "cause me less complexity
and pain".

> I agree with Sergio that this is a description of an implementation, not
> an use case (and that it's useless for use cases that involve the RTP
> ecosystem, which means that the use case you have in mind isn't one of
> Sergio's use cases).
> --
> Surveillance is pervasive. Go Dark.
Received on Monday, 21 May 2018 18:36:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:41 UTC