Adding "adapter" ORTC objects on top of ChannelManager/BaseChannel/etc.

webrtc/api/rtptransportcontrollerinterface.h

+/*
+ *  Copyright 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_API_RTPTRANSPORTCONTROLLERINTERFACE_H_
+#define WEBRTC_API_RTPTRANSPORTCONTROLLERINTERFACE_H_
+
+#include <vector>
+
+#include "webrtc/api/rtptransportinterface.h"
+
+namespace webrtc {
+
+class RtpTransportControllerShim;
+
+// Used to group RTP transports for the purpose of sharing bandwidth estimation
+// and other things that exist on a "per-call" basis.

[pthatcher1, 2017/02/08 01:33:49]

I think a better way to phrase this (instead of "per-call") would be that many
RtpTransports that are to the same remote endpoint should share an
RtpTransportController.  It may make sense to highlight that when bundling,
there will be only one RtpTransport per RtpTransportController, and there are
only many when not bundling.

[Taylor Brandstetter, 2017/02/10 00:19:45]

Done.

+//
+// RtpTransports are associated with this controller when they're created, by
+// passing the controller into OrtcFactory's relevant "CreateRtpTransport"
+// method. When they're destroyed, they're automatically removed.

[pthatcher1, 2017/02/08 01:33:49]

removed == not associated?
Might want to point out that GetTransports includes them when associated, and
not after removal.

+//
+// This is the RTP equivalent of "IceTransportController".

[pthatcher1, 2017/02/08 01:33:49]

I'm not sure what value this comment brings to someone that will be reading it.

[Taylor Brandstetter, 2017/02/10 00:19:45]

If you're familiar with the ORTC object heirarchy, you may be confused about
what an RtpTransportController represents. But it makes sense when you realize
"RtpTransportController is to RtpTransport as IceTransportController is to
IceTransport". I'll make this more clear.

+class RtpTransportControllerInterface {
+ public:
+  virtual ~RtpTransportControllerInterface() {}
+
+  // Returns all transports that are controlled by this controller and
+  // haven't yet been destroyed.
+  virtual std::vector<RtpTransportInterface*> GetTransports() const = 0;
+
+ protected:
+  // Only for internal use.
+  // Returns a pointer to the internal (non-public) interface.
+  virtual RtpTransportControllerShim* GetInternal() = 0;

[pthatcher1, 2017/02/08 01:33:49]

I'm not a fan of "XShim".  Why not "XInternal"?

[Taylor Brandstetter, 2017/02/10 00:19:45]

There needs to be some name that differentiates these shim objects from the real
ones, assuming there's some point in time during our refactoring at which both
will exist. I'm open to suggestions, but "XInternal" seems like it would be
confusing.

+
+  // Classes that can use this internal interface.
+  friend class RtpTransportShim;
+};
+
+}  // namespace webrtc
+
+#endif  // WEBRTC_API_RTPTRANSPORTCONTROLLERINTERFACE_H_