Introduce RtpStreamReceiver and RtpStreamReceiverControllerInterface.

webrtc/call/rtp_transport_controller_receive_interface.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_RECEIVE_INTERFACE_H_
+#define WEBRTC_CALL_RTP_TRANSPORT_CONTROLLER_RECEIVE_INTERFACE_H_
+
+#include <memory>
+
+#include "webrtc/call/rtp_demuxer.h"
+
+namespace webrtc {
+
+class RtpTransportReceiver {

[pthatcher1, 2017/05/17 23:24:53]

What is this?  No comment.  No methods.

And I'm guessing is should have the "Interface" suffix.

+ public:
+  virtual ~RtpTransportReceiver() {}
+};
+
+// This class acts as a factory for RtpTransportReceive objects.
+class RtpTransportControllerReceiveInterface {

[pthatcher1, 2017/05/17 23:24:53]

I still don't like this name.  RtpReceiverControllerInterface might be a better
one.

[nisse-webrtc, 2017/05/18 08:45:43]

I'm open to renaming (as long as RtpTransportControllerSender(Interface)? should
be consistently renamed). Shouldn't "Transport" be part of the name. Or is
"Session" better, "RtpSessionReceiver"? 

Then Danil suggested that we should have one class responsible for the
per-packet processing, (parsing, demuxing, interfacing to the congestion
controller) and a separate "controller" class responsible for ownership,
configuration, and book-keeping above the packet level. And "Session" might be
more appropriate for the former class.

[pthatcher1, 2017/05/24 03:57:38]

A controller is a thing that creates, owns, and destroys other things, like the
exiting TransportController, which create, owns, and destroys transports.  

So what does this controller create?  It seems to create RtpReceiver (thus, a
CreateReceiver method).  So then why not call it an RtpReceiverController?

Demuxing is complex enough that it ought to go in its own RtpDemuxer class.  

It wouldn't be a good idea to mix demuxing and creating receivers because then a
receiver cannot move between demuxers (which happens when we go from unbundled
to bundled).

I don't think we should use "RtpSession" except to refer to that very specific
thing: an RTP session (an SSRC space).  But that's basically what an RtpDemuxer
is, and the word Demuxer is much more clear.  Session is already very
overloaded.  

+ public:
+  virtual ~RtpTransportControllerReceiveInterface() {}
+  virtual std::unique_ptr<RtpTransportReceiver> CreateReceiver(

[pthatcher1, 2017/05/17 23:24:53]

This could use a method also.  You put in a sink and you get back a receiver. 
But what *is* a receiver?

[nisse-webrtc, 2017/05/18 08:45:43]

On an abstract level, a receiver is a handle to the Rtp-specific machinery which
feeds the RtpPacketSink.

A agree the class definition (above) deserves a comment.

+      uint32_t ssrc,
+      RtpPacketSinkInterface* sink) = 0;
+};

[danilchap, 2017/05/19 15:37:43]

OnRtpPacket or similar likely should be part of the interface too.
or RtpTransportController should implement two interfaces: one is this one and
another one is webrtc::Transport [or similar]

May be compose some tests to show how RtpTransportControllerReceiveInterface
supposed to be used.

if you keep CreateReceiver non-const, but make
OnRtpPacket const, then external read-write lock may be natural to control
synchronization of this interface.

[nisse-webrtc, 2017/05/22 07:09:37]

If we add that interface, I think it should take a raw, unparsed, packet. Do you
agree? And then we'd need to move around responsibility for IdentifyExtensions
before doing that.
Test would have to target the implementation class, right?

+
+}  // namespace webrtc
+
+#endif  // WEBRTC_CALL_RTP_TRANSPORT_CONTROLLER_RECEIVE_INTERFACE_H_