Fix the generation mismatch assertion error.

webrtc/p2p/base/p2ptransportchannel.cc

 /*
  *  Copyright 2004 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 648 matching lines @@
   } else {
     LOG(LS_INFO) << "Not switching the best connection on controlled side yet,"
                  << " because it's not writable: " << conn->ToString();
     pending_best_connection_ = conn;
   }
 }
 
 void P2PTransportChannel::OnCandidate(const Candidate& candidate) {
   ASSERT(worker_thread_ == rtc::Thread::Current());
 
+  uint32 generation = candidate.generation();
+  if (generation != 0 && generation < remote_candidate_generation_) {
+    LOG(LS_WARNING) << "Dropping a remote candidate because its generation "
+                    << generation
+                    << " is lower than the current remote generation "
+                    << remote_candidate_generation_;
+    return;
+  }
+
   // Create connections to this remote candidate.
   CreateConnections(candidate, NULL, false);
 
   // Resort the connections list, which may have new elements.
   SortConnections();
 }
 
 // Creates connections from all of the ports that we care about to the given
 // remote candidate.  The return value is true if we created a connection from
 // the origin port.
 bool P2PTransportChannel::CreateConnections(const Candidate& remote_candidate,
                                             PortInterface* origin_port,
                                             bool readable) {
   ASSERT(worker_thread_ == rtc::Thread::Current());
 
   Candidate new_remote_candidate(remote_candidate);

[pthatcher1, 2015/07/29 21:09:42]

Can you move the generation check down here and remove
GetRemoteCandidateGeneration?  It's duplicate with the check you are doing.

[honghaiz3, 2015/07/30 17:16:16]

If we move it down here, it means that even if it is a candidate with old
generation, we will still do the SortConnection() (after an early return in this
method), which may not be needed. Well, I guess we can use the return value of
CreateConnections to determine if we should do sort but the logic will be
somewhat different from the current one. 
Plus I only filtered the candidates with a smaller generation. If something
bigger came in, it is still an ASSERT error. Plus GetRemoteCandidateGeneration
has a different value depending on whether it is G-ICE, although maybe no one is
using G-ICE?

   new_remote_candidate.set_generation(
       GetRemoteCandidateGeneration(remote_candidate));
   // ICE candidates don't need to have username and password set, but
   // the code below this (specifically, ConnectionRequest::Prepare in
   // port.cc) uses the remote candidates's username.  So, we set it
   // here.
   if (remote_candidate.username().empty()) {
     new_remote_candidate.set_username(remote_ice_ufrag_);
   }
   if (remote_candidate.password().empty()) {
@@ skipping 713 matching lines @@
   SignalReadPacket(this, data, len, packet_time, 0);
 }
 
 void P2PTransportChannel::OnReadyToSend(Connection* connection) {
   if (connection == best_connection_ && writable()) {
     SignalReadyToSend(this);
   }
 }
 
 }  // namespace cricket