Switch voice transport to use Call and Stream instead of VoENetwork.

webrtc/call/call.cc

Index: webrtc/call/call.cc
diff --git a/webrtc/call/call.cc b/webrtc/call/call.cc
index 1572720248de200d4606b0fba140d0fb91874b74..22ca0f39f658ec477b230bc00f1145546476e426 100644
--- a/webrtc/call/call.cc
+++ b/webrtc/call/call.cc
@@ -750,8 +750,7 @@ PacketReceiver::DeliveryStatus Call::DeliverRtcp(MediaType media_type,
                                                  const uint8_t* packet,
                                                  size_t length) {
   TRACE_EVENT0("webrtc", "Call::DeliverRtcp");
-  // TODO(pbos): Figure out what channel needs it actually.
-  //             Do NOT broadcast! Also make sure it's a valid packet.
+  // TODO(pbos): Make sure it's a valid packet.
   //             Return DELIVERY_UNKNOWN_SSRC if it can be determined that
   //             there's no receiver of the packet.
   received_rtcp_bytes_ += length;
@@ -759,25 +758,35 @@ PacketReceiver::DeliveryStatus Call::DeliverRtcp(MediaType media_type,
   if (media_type == MediaType::ANY || media_type == MediaType::VIDEO) {

[the sun, 2016/04/22 12:40:31]

In Call::DeliverRtp, packets are forwarded to audio streams first - is there any
point in using the same order in both methods?

[mflodman, 2016/04/27 13:42:17]

I don't think it really matters, but my assumption is that BWE related RTCP are
currently sent to video streams and it makes sense to process them asap. In
practice it might not really make a difference, so I can change if you'd like.

[the sun, 2016/04/28 09:15:56]

No, but add a comment about that.

     ReadLockScoped read_lock(*receive_crit_);
     for (VideoReceiveStream* stream : video_receive_streams_) {
-      if (stream->DeliverRtcp(packet, length)) {
+      if (stream->DeliverRtcp(packet, length))
+        rtcp_delivered = true;
+    }
+  }
+  if (media_type == MediaType::ANY || media_type == MediaType::AUDIO) {

[the sun, 2016/04/22 12:40:31]

if media_type == ANY, is it ok that packets *may* be forwarded to both audio and
video streams?

[mflodman, 2016/04/27 13:42:17]

I thought about this and I'm not sure what the standard really says in this
case, if it's ok to bundle report blocks for different media types in the same
RTCP RR.

I prefer it this way, talk with people that knows and then restrict if that is
not allowed.

[the sun, 2016/04/28 09:15:56]

Acknowledged.

+    ReadLockScoped read_lock(*receive_crit_);
+    for (auto& kv : audio_receive_ssrcs_) {
+      if (kv.second->DeliverRtcp(packet, length))
         rtcp_delivered = true;
-        if (event_log_)
-          event_log_->LogRtcpPacket(kIncomingPacket, media_type, packet,
-                                    length);
-      }
     }
   }
   if (media_type == MediaType::ANY || media_type == MediaType::VIDEO) {
     ReadLockScoped read_lock(*send_crit_);
     for (VideoSendStream* stream : video_send_streams_) {
-      if (stream->DeliverRtcp(packet, length)) {
+      if (stream->DeliverRtcp(packet, length))
         rtcp_delivered = true;
-        if (event_log_)
-          event_log_->LogRtcpPacket(kIncomingPacket, media_type, packet,
-                                    length);
-      }
     }
   }
+  if (media_type == MediaType::ANY || media_type == MediaType::AUDIO) {
+    ReadLockScoped read_lock(*send_crit_);
+    for (auto& kv : audio_send_ssrcs_) {
+      if (kv.second->DeliverRtcp(packet, length))
+        rtcp_delivered = true;
+    }
+  }
+
+  if (event_log_ && rtcp_delivered)
+    event_log_->LogRtcpPacket(kIncomingPacket, media_type, packet, length);
+
   return rtcp_delivered ? DELIVERY_OK : DELIVERY_PACKET_ERROR;
 }