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

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.

Received on Monday, 21 May 2018 20:45:06 UTC