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

Re: Use cases / requirements for raw data access functions

From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Mon, 21 May 2018 21:21:59 +0200
To: public-webrtc@w3.org
Message-ID: <5d507fa7-ef4b-fc59-18e2-9810f9fdcd42@gmail.com>
On 21/05/2018 20:35, Peter Thatcher wrote:
> On Sun, May 20, 2018 at 9:08 PM Harald Alvestrand 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>     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 
> https://docs.google.com/forms/d/1YVKqVU_ziCYtp8RGGnwB8WcQWDhkXe-mOmaSkFTdJm8/viewanalytics).

I agree that end to end media encryption and attach custom metadata to a 
media frame are very interesting use cases, in fact, send them already 
to the list myself. But they can also be implemented over RTP, so I 
think it is just too early to jump into how should we implement them.

Best regards
Received on Monday, 21 May 2018 19:21:42 UTC

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