- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Thu, 14 Jun 2018 18:59:04 +0000
- To: Peter Thatcher <pthatcher@google.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Peter said: "What about splitting out the RtpTransport from the RtpSender? A. new method RtpSender.setTransport(transport) B. new method RtpTransport.addSender(RtpSender) C. WHATWG streams: RtpTransport.sendPackets = RtpSender.packets Again, we have to worry about feedback from sink to source. A seems the best approach for that." [BA] The RtpSender is currently very (S)RTP-centric. For example, RTCRtpParameters intermingles (S)RTP/RTCP-related information with things that relate to the encoder. Part of the reason that RTP/RTCP and encoding parameters are so inter-twined is to enable incoming RTP and RTCP packets to be routed to the appropriate RtpReceivers, and within the receivers, to be separated out into the appropriate layers (e.g. simulcast, SVC, etc.). For that reason, it would not be easy to disentangle the RtpSender from RTP. To date setTransport() has been used for setting different transports for the (S)RTP provided by RtpSender (e.g. SRTP keyed with DTLS-SRTP or SRTP/SDES). So if you were to call RtpSender.setTransport (quicTransport), the assumption would be that RTP was being transported somehow (either SRTP keyed via QUIC-SRTP, or RTP over QUIC).
Received on Thursday, 14 June 2018 18:59:30 UTC