Update prflx candidates' generation when setting ICE credentials.

webrtc/p2p/base/port.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 1280 matching lines @@
   bool use_candidate = use_candidate_attr();
   LOG_JV(sev, this) << "Sent STUN ping"
                     << ", id=" << rtc::hex_encode(request->id())
                     << ", use_candidate=" << use_candidate;
 }
 
 void Connection::HandleRoleConflictFromPeer() {
   port_->SignalRoleConflict(port_);
 }
 
-void Connection::MaybeSetRemoteIceCredentials(const std::string& ice_ufrag,
-                                              const std::string& ice_pwd) {
-  if (remote_candidate_.username() == ice_ufrag &&
-      remote_candidate_.password().empty()) {
-    remote_candidate_.set_password(ice_pwd);
+void Connection::MaybeSetRemoteIceCredentialsAndGeneration(
+    const std::vector<IceParameters>& remote_ice_parameters) {
+  int generation = 0;
+  for (const IceParameters& params : remote_ice_parameters) {
+    if (remote_candidate_.username() == params.ufrag &&
+        remote_candidate_.password().empty()) {
+      remote_candidate_.set_password(params.pwd);

[pthatcher1, 2016/04/12 18:47:39]

Should we also set_generation() here?

[Taylor Brandstetter, 2016/04/12 21:33:46]

I guess it would be a small optimization. Or do we not need the below block of
code at all? Is it assured that if you don't have a generation, you also don't
have a password?

[pthatcher1, 2016/04/12 22:39:53]

Oh, I see.  In the first case, you end up doing the second case also.  That
wasn't obvious to me.    Maybe calling set_generation() here and changing it to
an else if in the second case would be more readable.  But it's not worth doing
for the sake of an optimization.

You might have a generation but not a password.  But I can't think of how you'd
have a password but not a generation, unless we started trickling the password
also.  Actually, that might happen in the future, so maybe just keep this robust
like you have it.

+    }
+    if (remote_candidate_.username() == params.ufrag &&
+        remote_candidate_.password() == params.pwd) {
+      remote_candidate_.set_generation(generation);
+    }
+    ++generation;
   }
 }
 
 void Connection::MaybeUpdatePeerReflexiveCandidate(
     const Candidate& new_candidate) {
   if (remote_candidate_.type() == PRFLX_PORT_TYPE &&
       new_candidate.type() != PRFLX_PORT_TYPE &&
       remote_candidate_.protocol() == new_candidate.protocol() &&
       remote_candidate_.address() == new_candidate.address() &&
       remote_candidate_.username() == new_candidate.username() &&
@@ skipping 124 matching lines @@
     ASSERT(sent < 0);
     error_ = port_->GetError();
     sent_packets_discarded_++;
   } else {
     send_rate_tracker_.AddSamples(sent);
   }
   return sent;
 }
 
 }  // namespace cricket