Define RtpTransportControllerSendInterface.

webrtc/call/rtp_transport_controller.h

+/*
+ *  Copyright (c) 2017 The WebRTC project authors. All Rights Reserved.
+ *
+ *  Use of this source code is governed by a BSD-style license
+ *  that can be found in the LICENSE file in the root of the source
+ *  tree. An additional intellectual property rights grant can be found
+ *  in the file PATENTS.  All contributing project authors may
+ *  be found in the AUTHORS file in the root of the source tree.
+ */
+
+#ifndef WEBRTC_CALL_RTP_TRANSPORT_CONTROLLER_H_
+#define WEBRTC_CALL_RTP_TRANSPORT_CONTROLLER_H_
+
+namespace webrtc {
+
+class CongestionController;
+class Module;
+class PacketRouter;
+class RtpPacketSender;
+class TransportFeedbackObserver;
+class VieRemb;
+
+// An RtpTransportController should own everything related to the RTP
+// transport to/from a remote endpoint. We should have separate
+// interfaces for send and receive side, even if they are implemented
+// by the same class. This is an ongoing refactoring project. At some
+// point, this class should be promoted to a public api under
+// webrtc/api/rtp/.
+//
+// For a start, this object is just a collection of the objects needed
+// by the VideoSendStream constructor. The plan is to move ownership
+// of all RTP-related objects here, and add methods to create per-ssrc
+// objects which would then be passed to VideoSendStream.

[danilchap, 2017/03/14 17:59:14]

May be add a comment that direct accessors (remb(), packet_router(), etc.)
probably should be eventually removed when interface will be filled with
stream factories like
std::unique_ptr<PerSsrcObject> CreateStream(uint32_t ssrc, ...);
helper functions, e.g.
void GetStats(Stats* out) const;
void SetApplicationLimitedSendBitrate(int max_bitrate_bps);
and input function(s), i.e.
void ProcessRtcpPacket(rtc::Buffer raw_packet);

[nisse-webrtc, 2017/03/15 08:06:23]

Done.

+//
+// This should also have a reference to the underlying
+// webrtc::Transport. Currently, webrtc::Transport is implemented by

[Taylor Brandstetter, 2017/03/14 23:08:35]

"webrtc::Transport(s)", since there may be multiple? I'm still assuming that
when audio/video use separate ports, there are two webrtc::Transports and one
RtpTransportController.

[nisse-webrtc, 2017/03/15 08:06:23]

Updated the comment. On the underlying question, I'm not sure I agree. My
thinking has been that Call::CreateVideoSendStream would pass a
RtpTransportControllerSendInterface to the constructor of VideoSendStream. And
VideoSendStream would then ask it it to create two per-ssrc objects, one for
media and one for RTX. 

But if RtpTransportControllerSendInterface represents multiple transports, how
would VideoSendStream know which transport to use? It shouldn't need to know
anything about that.

Maybe one could move creation of the per-ssrc objects to Call (it makes some
sense that Call is aware about transports and bundled vs unbundled), but the
drawback is that Call then would need to knwo about RTX. Or have a sepatate
Call::CreateVideoRtxStream. So it's a bit tricky to get right.

Thinking aloud, one possible solution might be to let the RtpTransportController
object handle multiple transports, but expose one
RtpTransportControllerSendInterface per transport.

[Taylor Brandstetter, 2017/03/15 21:39:07]

I think we may be using the same name (RtpTransportController) to refer to
different things.

In the model I had in mind, "RtpTransport" is something that encapsulates the
underlying packet transport(s) (one if RTCP muxing is used, two otherwise), and
represents an independent RTP session/SSRC namespace.

"RtpTransportController" is something that comes into play when media is not
bundled, meaning there are separate "RtpTransport"s for audio and video, but
attached to the same RtpTransportController in order to share a congestion
controller, do A/V sync, etc.

It seems like what you're calling "RtpTransportController", I'm calling
"RtpTransport". I'm open to changing names or changing the model I just
described, but we should clear up this distinction before it gets too late.

+// WebRtcVideoChannel2 and WebRtcVoiceMediaChannel, and owned by
+// WebrtcSession. Video and audio always uses different transport
+// objects, even in the common case where they are bundeled over the

[Taylor Brandstetter, 2017/03/14 23:08:35]

"bundled"

[nisse-webrtc, 2017/03/15 08:06:23]

Done.

+// same underlying transport.
+//
+// Extracting the logic of the webrtc::Transport from BaseChannel and
+// subclasses into a separate class seems to be a prerequesite for
+// moving the transport here.
+class RtpTransportControllerSendInterface {
+ public:
+  virtual ~RtpTransportControllerSendInterface() {}
+  virtual VieRemb* remb() = 0;
+  virtual PacketRouter* packet_router() = 0;
+
+  // Currently returning the same pointer, but with different types.
+  virtual CongestionController* congestion_controller() = 0;
+  virtual TransportFeedbackObserver* transport_feedback_observer() = 0;
+
+  virtual RtpPacketSender* packet_sender() = 0;
+};
+
+}  // namespace webrtc
+
+#endif  // WEBRTC_CALL_RTP_TRANSPORT_CONTROLLER_H_