Make the audio channel communicate network state changes to the call.

webrtc/call/call.cc

Index: webrtc/call/call.cc
diff --git a/webrtc/call/call.cc b/webrtc/call/call.cc
index 41ac328eab14f44249a20d7ac0dba85a36bb9d1d..5c95d7941f8675828bfee7b962b082a88d1293c3 100644
--- a/webrtc/call/call.cc
+++ b/webrtc/call/call.cc
@@ -550,6 +550,10 @@ void Call::SetBitrateConfig(
 
 void Call::SignalNetworkState(NetworkState state) {
   RTC_DCHECK(configuration_thread_checker_.CalledOnValidThread());
+  // TODO(skvlad): In the unbundled case the network state might be different
+  // for the audio and video channels. Currently the last change wins.
+  // Correctly handling this scenario would require tracking the network state
+  // for each media type separately.

[stefan-webrtc, 2016/03/02 08:25:59]

Do we think this is a common scenario? In that case maybe it's actually better
to still allow audio to be sent even though the network might be down, just to
avoid no audio in the special case when only the video connection is down? 

[pbos-webrtc, 2016/03/02 12:54:34]

Does this risk audio/video network states being out of sync? That sounds scary
to me.

[skvlad, 2016/03/02 18:44:05]

This sounds like a good idea - let's keep the special case to allow sending
audio until correct state tracking is implemented.

[skvlad, 2016/03/02 18:44:05]

Currently the audio/video MediaChannels each determine their own state based on
the information they receive from their respective transport. These can
technically be out of sync, and this CL does not change that.
What changes, though, is that previously only the state of the VideoChannel
would affect the state of the audio and video streams, and of the pacer. After
this change, the last state signaled by either the video or the audio stream -
whichever happens last - controls these states. This makes the state be
correctly set in the case of a call answered with audio only, where the video
stream is never started.
In other words, the out-of-sync condition could already be happening and this
change should not be affecting its frequency. What it adds is the ability to
handle audio-only calls in a slightly more correct way.
Eliminating any possibility of an out-of-sync state seems to involve a fairly
extensive refactoring - this TODO is there to indicate that.

   network_enabled_ = state == kNetworkUp;
   congestion_controller_->SignalNetworkState(state);
   {