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

webrtc/call/call.cc

 /*
  *  Copyright (c) 2013 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.
  */
 
@@ skipping 532 matching lines @@
     return;
   }
   config_.bitrate_config = bitrate_config;
   congestion_controller_->SetBweBitrates(bitrate_config.min_bitrate_bps,
                                          bitrate_config.start_bitrate_bps,
                                          bitrate_config.max_bitrate_bps);
 }
 
 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);
   {
     ReadLockScoped write_lock(*send_crit_);
     for (auto& kv : audio_send_ssrcs_) {
       kv.second->SignalNetworkState(state);
     }
     for (auto& kv : video_send_ssrcs_) {
       kv.second->SignalNetworkState(state);
     }
@@ skipping 181 matching lines @@
   // thread. Then this check can be enabled.
   // RTC_DCHECK(!configuration_thread_checker_.CalledOnValidThread());
   if (RtpHeaderParser::IsRtcp(packet, length))
     return DeliverRtcp(media_type, packet, length);
 
   return DeliverRtp(media_type, packet, length, packet_time);
 }
 
 }  // namespace internal
 }  // namespace webrtc