Re: Transport / encoder coupling (Re: Use cases / requirements for raw data access functions)

You just described ORTC, except that you replaced an RtpSender with an
RtpTransport, which I think is a good idea.

I think the key questions left are:

- What does the encoder/decoder part of the RtpSender look like?
- How low-level is the RtpTransport?  Is it "send frame" or "send packet"?


On Mon, May 21, 2018 at 1:47 PM Harald Alvestrand <harald@alvestrand.no>
wrote:

> On 05/21/2018 06:26 PM, Bernard Aboba wrote:
> > Sergio said:
> >
> > "We should separate transports from encoders (split the RtpSender in
> half) to give more flexibility to apps."
> >
> > [BA] Splitting the RtpSender/Receiver in half would separate the encoder
> from (S)RTP payload encapsulation.
> >
> > Siince the thread is about use cases, we should try to be clear what the
> end goal is.
> >
> > Even if the end goal is about encapsulation of media in QUIC, there can
> be multiple ways to do this:  media over QUIC versus media over HTTP/2 over
> QUIC, for example.
> >
> >
> > Harald said:
> >
> > " specifications of "what happens when you couple a transport with an
> encoder"
> >
> > [BA] The current object model is not entirely clear about this.
> >
> > The current transport objects (e.g. DtlsTransport) sometimes indicate
> use to encapsulate data (data channel) and sometimes just key management
> (e.g. DTLS-SRTP) with a (non-represented) SRTP transport.
> >
> > For example, DataChannel -> SctpTransport -> DtlsTransport implies data
> channel messages transported via Sctp and secured with DTLS.
> >
> > However, with audio/video alternative meanings may be implied (or not).
> >
> > Sender -> RtpTransport -> DtlsTransport would probably imply use of SRTP
> keyed by DTLS-SRTP.
> >
> > Does this imply that Sender -> RtpTransport -> QuicTransport means use
> of SRTP keyed by QUIC-SRTP?
> >
> > Or might it instead mean protection of RTP packets within QUIC?
>
> My thinking: In modelling "classic WebRTC", we can have:
>
> - an UdpTransport that provides only the function of pushing data, and
> (crucially) does NOT provide this function to the Javascript user. It is
> a control surface only. (This might be the IceTransport or something
> that the IceTransport manipulates; not sure about this.)
>
> - a DtlsTransport object that has two functions: Pushing data protected
> by DTLS and providing keys. It's initialized with an UdpTransport.
>
> - an SrtpTransport that has the function of pushing RTP data (exposed to
> the user?) - it is initialized with an UdpTransport and a DtlsTransport.
>
> - an SctpTransport that has the function of pushing Sctp-wrapped data
> packets (exposed to the user) - initialized with a DtlsTrasnport
>
> Sctp and Srtp would know about congestion control - possibly they're
> initialized with a (shared) congestion controller object. Dtls and Udp
> would not.
>
> That's a close model of how RTP works today. A QuicTransport would then
> be initialized with an UdpTransport, but not a DtlsTransport, and not
> provide the key-vending interface.
>
> --
> Surveillance is pervasive. Go Dark.
>
>
>
>