Create RtcpDemuxer

webrtc/call/rtcp_packet_sink_interface.h

Index: webrtc/call/rtcp_packet_sink_interface.h
diff --git a/webrtc/call/rtcp_packet_sink_interface.h b/webrtc/call/rtcp_packet_sink_interface.h
new file mode 100644
index 0000000000000000000000000000000000000000..d4254c91b6337b69ebc28d7e8fa129358784e540
--- /dev/null
+++ b/webrtc/call/rtcp_packet_sink_interface.h
@@ -0,0 +1,29 @@
+/*
+ *  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_RTCP_PACKET_SINK_INTERFACE_H_
+#define WEBRTC_CALL_RTCP_PACKET_SINK_INTERFACE_H_
+
+#include "webrtc/base/array_view.h"
+
+namespace webrtc {
+
+// This class represents a receiver of an unparsed RTCP packet.
+// TODO(eladalon): Replace this by demuxing over parsed rather than raw data.
+// Whether this should be over an entire RTCP packet, or over RTCP blocks,
+// is still under discussion.
+class RtcpPacketSinkInterface {

[danilchap, 2017/06/16 16:46:19]

May be it will be simpler to merge this sink into RtpPacketSinkInterface, but
instead of making it pure virtual interface, have default implementations that
do nothing (that will be usuful when OnRtcpPacket will be split in many
individual rtcp messages - sink will need to implement only those it cares
about).

That might remove complexity of observers (registering them, ensuring  none left
at destruction, etc) and remove code duplication between rtp_demuxer and
rtcp_demuxer.

Do you know a use case that will be missed with that design?

[nisse-webrtc, 2017/06/19 08:26:51]

I prefer to keep RtpPacketSinkInterface independent of RTCP. I expect RTCP to be
terminated at a higher level in the stack than RTP, and that many
implementations of RtpPacketSinkInterface wouldn't care at all about RTCP. Sure,
default implementations of the methods would work, but I think we'd lose clarity
in that it gets less obvious which classes care about RTCP.

And we were just able to drop the RTCP callback from the related class RtpData
(cl https://codereview.webrtc.org/2886813002)...

[eladalon, 2017/06/19 11:28:47]

I'll add that multiple calls to a virtual function that ends up doing nothing
are nice to avoid.

+ public:
+  virtual ~RtcpPacketSinkInterface() {}
+  virtual void OnRtcpPacket(rtc::ArrayView<const uint8_t> packet) = 0;
+};
+
+}  // namespace webrtc
+
+#endif  // WEBRTC_CALL_RTCP_PACKET_SINK_INTERFACE_H_