Initial implementation of RtpTransportControllerReceive and related interfaces.

webrtc/call/rtp_transport_controller_receive.h

Index: webrtc/call/rtp_transport_controller_receive.h
diff --git a/webrtc/call/rtp_transport_controller_receive.h b/webrtc/call/rtp_transport_controller_receive.h
new file mode 100644
index 0000000000000000000000000000000000000000..cf45a504e7b3365668de478a1b1f6e09bef1c35f
--- /dev/null
+++ b/webrtc/call/rtp_transport_controller_receive.h
@@ -0,0 +1,108 @@
+/*
+ *  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_RECEIVE_H_
+#define WEBRTC_CALL_RTP_TRANSPORT_CONTROLLER_RECEIVE_H_
+
+#include <memory>
+
+#include "webrtc/base/array_view.h"
+
+// For DeliveryStatus.
+// TODO(nisse): This file ought to not depend on call.
+#include "webrtc/call/call.h"
+
+namespace webrtc {
+
+class ReceiveSideCongestionController;
+class RtpPacketReceived;
+
+// This class represents a receiver of already parsed RTP packets.
+class RtpPacketSinkInterface {
+ public:
+  virtual ~RtpPacketSinkInterface() {}
+  virtual void OnRtpPacket(const RtpPacketReceived& packet) = 0;
+};
+
+// TODO(nisse): This additional interface may be a bit confusing, it's
+// needed because RTP extensions are currently associated with each
+// stream. We should be able to identify extensions earlier, since the
+// mapping is the same for all streams on the same transport. Then we
+// can delete this class, replacing it with RtpPacketSinkInterface.
+// There's also the subtlety that the per-transport negotiation may
+// differ from the extensions expected for a particular stream, and we
+// may have code that breaks if we identify extension which is not
+// consistent with the configuration of the stream.
+
+// This class represents a receiver of RTP packets, which has the
+// additional responsibility of identifying extension headers. I.e.,
+// the caller of OnRtpPacketReceive is expected to have called
+// packet->Parse, but not packet->IdentifyExtensions.
+class RtpPacketReceiverInterface {
+ public:
+  virtual ~RtpPacketReceiverInterface() {}
+  virtual bool OnRtpPacketReceive(RtpPacketReceived* packet) = 0;
+};
+
+// This class represents the RTP receive parsing and demuxing, for a
+// single transport. It isn't thread aware, leaving responsibility of
+// multithreading issues to the user of this class. TODO(nisse): Add
+// RTCP processing, we should aim to terminate RTCP and not leave any
+// RTCP processing to individual receive streams. TODO(nisse): Extract
+// parsing and demuxing logic into separate classes. A demuxer should
+// handle only a single transport.
+class RtpTransportControllerReceiveInterface {
+ public:
+  // Configuration needed for media-independent processing of received
+  // packets, in particular, feeding information to the congestion
+  // controller.
+
+  // TODO(nisse): It turns out this data is only used for the callback

[danilchap, 2017/04/25 09:33:40]

what (and when) should be done about it?

[nisse-webrtc, 2017/04/25 11:22:50]

I'm rephrasing the comment. There's nothing obvious to do about it,
beside some general simplification of how the various bitrate estimators are
used.

+  // to the ReceiveSideCongestionController.
+  struct Config {
+    // See draft-holmer-rmcat-transport-wide-cc-extensions for details.
+    bool use_send_side_bwe = false;

[danilchap, 2017/04/25 09:33:40]

why controller itself configured with 'enable_receive_side_bwe' and each
individual receiver configured with 'use_send_side_bwe'
Can you put comments what each of those two parameters mean?

[nisse-webrtc, 2017/04/25 11:22:50]

|enable_receive_side_bwe| used to be a check of the MediaType, needed to make
some audio tests pass. Without it, we generated unexpected REMB packets, iirc.
This isn't pretty. I could try deleting |enable_receive_side_bwe| and run the
bots, to see if it's still needed and how to fix it. 

+  };
+
+  // Creates the default implementation.
+  static std::unique_ptr<RtpTransportControllerReceiveInterface> Create(
+      ReceiveSideCongestionController* receive_side_cc,
+      bool enable_receive_side_bwe);
+
+  virtual ~RtpTransportControllerReceiveInterface() {}
+
+  // Registers the receiver responsible for an ssrc.
+  virtual void AddReceiver(uint32_t ssrc,
+                           const Config& config,
+                           RtpPacketReceiverInterface* receiver) = 0;
+  // TODO(nisse): It's unclear what info is conveniently available at
+  // remove time. For now, we take only the |receiver| pointer and
+  // iterate over the mapping.
+  virtual void RemoveReceiver(const RtpPacketReceiverInterface* receiver) = 0;
+
+  // Used to represent auxillary sinks, currently used for FlexFec.
+  // The responsible receiver must be registered first.
+  virtual void AddSink(uint32_t ssrc, RtpPacketSinkInterface* sink) = 0;
+  // TODO(nisse): It's unclear what info is conveniently available at
+  // remove time. For now, we take only the |receiver| pointer and
+  // iterate over the mapping.
+  virtual void RemoveSink(const RtpPacketSinkInterface* sink) = 0;
+
+  // Process raw incoming RTP packets.
+  // TODO(nisse): DeliveryStatus is needed for the current handling of
+  // unsignalled ssrcs. Change return type to bool or void, once we do
+  // that via AddPayload instead.
+  virtual PacketReceiver::DeliveryStatus OnRtpPacket(
+      int64_t arrival_time_ms,
+      rtc::ArrayView<const uint8_t> packet) = 0;
+};
+
+}  // namespace webrtc
+
+#endif  // WEBRTC_CALL_RTP_TRANSPORT_CONTROLLER_RECEIVE_H_