- From: Peter Thatcher <pthatcher@google.com>
- Date: Mon, 21 May 2018 14:17:42 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAJrXDUH+ukT7u2TOzhN4PL4diMfYn1EzW7r8CvA-bjD2mgh-Zw@mail.gmail.com>
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. > > > >
Received on Monday, 21 May 2018 21:18:18 UTC