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

webrtc/audio/audio_receive_stream.cc

Index: webrtc/audio/audio_receive_stream.cc
diff --git a/webrtc/audio/audio_receive_stream.cc b/webrtc/audio/audio_receive_stream.cc
index 9c253894719278a48b354763b4aef0a3235d0817..8d04f978d7d62fd19fc9f58f158cff9f2070cdf5 100644
--- a/webrtc/audio/audio_receive_stream.cc
+++ b/webrtc/audio/audio_receive_stream.cc
@@ -150,7 +150,8 @@ bool AudioReceiveStream::DeliverRtcp(const uint8_t* packet, size_t length) {
   // calls on the worker thread. We should move towards always using a network
   // thread. Then this check can be enabled.
   // RTC_DCHECK(!thread_checker_.CalledOnValidThread());
-  return false;
+  return channel_proxy_->ReceivedRTCPPacket(static_cast<const uint8_t*>(packet),

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

Looks like this cast is not needed anymore?

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

Doh!

+                                            length) == 0;
 }
 
 bool AudioReceiveStream::DeliverRtp(const uint8_t* packet,
@@ -177,7 +178,8 @@ bool AudioReceiveStream::DeliverRtp(const uint8_t* packet,
     remote_bitrate_estimator_->IncomingPacket(arrival_time_ms, payload_size,

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

stefan: is it still appropriate to fork packets off for BWE here or should that
happen some other way (e.g. through the Channel's RtpRtcpModule)?

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

For video this is done in ViEReciever, that we're refactoring and this might end
up in VideoReceiveStream too. So I'd prefer to keep it here at lest for now
until this has been settled.

ok?

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

ok, just wanted to make sure we won't magically send packets twice to the RBE or
something.

[stefan-webrtc, 2016/04/28 09:27:48]

Should be fine, and I also prefer it being done this way.

                                               header, false);
   }
-  return true;
+
+  return channel_proxy_->ReceivedRTPPacket(packet, length, packet_time);

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

VoE::ReceivedRTPPacket() will:
  if ((length < 12) || (length > 1292)) {
    return -1;
  }
but it seems to me that we shouldn't make such a decision at that level, and I
can't find anything in the code that looks like it will break if the packet is <
12 bytes or > 1292 bytes. However, we should be aware that were potentially
opening up for abuse.

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

Channel::ReceivedRTPPacket is calling rtp_header_parser_->Parse(received_packet,
length, &header) right away and this will catch length < 12.

I can add back a check for too large packets if you think this is needed for
audio, I'm not very familiar with the potential risks there.

In that case, I can add that check in Channel::ReceivedRTPPacket rather than
here.

WDYT?

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

Yes, please add the check in Channel::ReceivedRTPPacket().

 }
 
 webrtc::AudioReceiveStream::Stats AudioReceiveStream::GetStats() const {