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

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?

Received on Monday, 21 May 2018 16:26:28 UTC