New class RtpDemuxer and RtpPacketSinkInterface, use in Call.

webrtc/call/rtp_demuxer.h

Index: webrtc/call/rtp_demuxer.h
diff --git a/webrtc/call/rtp_demuxer.h b/webrtc/call/rtp_demuxer.h
new file mode 100644
index 0000000000000000000000000000000000000000..2e90cf63ea481e1e5e436b087857298a59055837
--- /dev/null
+++ b/webrtc/call/rtp_demuxer.h
@@ -0,0 +1,50 @@
+/*
+ *  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_DEMUXER_H_
+#define WEBRTC_CALL_RTP_DEMUXER_H_
+
+#include <map>
+
+namespace webrtc {
+
+class RtpPacketReceived;
+
+// This class represents a receiver of an already parsed RTP packets.
+class RtpPacketSinkInterface {
+ public:
+  virtual ~RtpPacketSinkInterface() {}
+  virtual void OnRtpPacket(const RtpPacketReceived& packet) = 0;
+};
+
+// This class represents the RTP demuxing, for a single transport. It

[pthatcher1, 2017/05/10 00:04:21]

We should define "transport" here.  I think you mean it in the RTP sense of "one
SSRC space", but it should be made clear.

[nisse-webrtc, 2017/05/10 07:41:32]

I mean one SSRC space, and my understanding is that corresponds to one
transport, which is admittedly little fuzzy, but for a direct connection that
would be one 5-tuple, and with ice it would be one "ice session", I guess.

Can you suggest a concise and unambiguous term for that?

[Taylor Brandstetter, 2017/05/10 20:59:43]

RTP session? From RFC7656:

"An RTP session shares a single SSRC space"
"A single media transport always carries a single RTP session."

[pthatcher1, 2017/05/12 00:38:51]

That's exactly what I meant.  Basically quote/reference/summarize that here.

+// isn't thread aware, leaving responsibility of multithreading issues
+// to the user of this class.
+class RtpDemuxer {
+ public:
+  RtpDemuxer();
+  virtual ~RtpDemuxer();

[danilchap, 2017/05/09 09:20:22]

why this class has virtual functions?

[nisse-webrtc, 2017/05/09 12:11:49]

It's not needed for now, I'll remove virtual.

(To me, non-virtual member functions are so alien to object oriented programming
that I tend to not use that feature).

+
+  // Registers a sink. The same sink can be registered for multiple ssrcs.
+  virtual void AddSink(uint32_t ssrc, RtpPacketSinkInterface* sink);

[pthatcher1, 2017/05/10 00:04:21]

What happens if a single SSRC has multiple sinks added?  What happens if you
give a null sink?

[nisse-webrtc, 2017/05/10 07:41:32]

We can have multiple sinks for the same ssrc, e.g, a media stream and flexfex
receiver for a "flexfec group". Received packets are passed on to all sinks
registered for that ssrc.

We can also have the same sink registered on multiple ssrcs, e.g, the flexfec
case above, and also rtx. Although the latter should maybe be refactored at some
point to use a separate rtx receiver.

Use of null sinks, and repeated pairs of {ssrc, sink}, is not intended.

Speaking of flexfec, I and danil were a bit unsure of the flexfec scope. I'm
working under the assumption that a flexfec group can't span multiple
transports. I.e., each flexfec receiver belongs to one transport and it can
protect only media streams on that same transport. Correct?

[pthatcher1, 2017/05/12 00:38:51]

Could you make that clear in the comment?
Yes, that was clear from the comment.
I think we need to document what happens if a null or duplicate is passed in. 
Does it crash?  Does it return an error?  Does it just log a warning and ignore
you?  
It's my understanding that flexfec will not span multiple SSRC spaces (else how
could it reference two spaces that have the same SSRC?).  So, yes, I believe
that's correct.

[nisse-webrtc, 2017/05/12 08:50:08]

I'm updating the comments to say that null pointers are not allowed, and I'm
adding DCHECKs to back that up.

For repeated pairs of {ssrc, sink}, I don't think anything special happens, one
will just end up with duplicate entries in the underlying multimap.

+  // 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);
+
+  // Returns true if at least one matching sink was found, otherwise false.
+  virtual bool OnRtpPacket(const RtpPacketReceived& packet);
+
+ private:
+  std::multimap<uint32_t, RtpPacketSinkInterface*> sinks_;
+};
+
+}  // namespace webrtc
+
+#endif  // WEBRTC_CALL_RTP_DEMUXER_H_