Prepare for ICE-renomination

webrtc/p2p/base/p2ptransportchannel.h

 /*
  *  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 189 matching lines @@
   // Public for unit tests.
   PortAllocatorSession* allocator_session() {
     return allocator_sessions_.back().get();
   }
 
   // Public for unit tests.
   const std::vector<RemoteCandidate>& remote_candidates() const {
     return remote_candidates_;
   }
 
+  // Public for unit tests.
+  void set_peer_supports_renomination(bool peer_supports_renomination) {
+    peer_supports_renomination_ = peer_supports_renomination;
+  }

[pthatcher1, 2016/07/28 22:57:25]

I think we should make a new method, SetRemoteIceParameters that eventually will
also contain the ufrag and password (replace SetRemoteIceCredentials and
SetRemoteIceMode).  It would take a struct like this:

struct IceParameters {
  std::string ufrag;
  std::string pwd;
  IceMode mode;
  bool renomination;
}

Then we just have remote_parameters_ as the member variable.


For now, in this CL, I think we should add remote_parameters_ and
SetRemoteIceParameters, and have the struct be this:


struct IceParameters {
  // TODO: Add the following and replace SetRemoteIceCredentials and
SetRemoteIceMode.
  // std::string ufrag;
  // std::string pwd;
  // IceMode mode;
  bool renomination;
}

[honghaiz3, 2016/08/03 04:46:56]

The struct IceParameters is already there. In fact we have a list of remote
parameters and initially it may be empty. 
I think it would be simpler to make this change in a subsequent CL when I add
the signaling changes. Added TODO for this. 

[pthatcher1, 2016/08/03 22:13:25]

Oh good, let's add "bool renomination" to it and use it, then.  
If it's empty, then clearly we don't know the remote endpoint supports
renomination, so we shouldn't use it until we do.
I'm OK with you do that in a followup CL.

[honghaiz3, 2016/08/03 23:39:51]

Thanks. Will do it in the next CL. 

+
  private:
   rtc::Thread* thread() const { return worker_thread_; }
   bool IsGettingPorts() { return allocator_session()->IsGettingPorts(); }
 
   // A transport channel is weak if the current best connection is either
   // not receiving or not writable, or if there is no best connection at all.
   bool weak() const;
   // Returns true if it's possible to send packets on this channel.
   bool ReadyToSend() const;
   void UpdateConnectionStates();
@@ skipping 176 matching lines @@
   uint64_t tiebreaker_;
   IceGatheringState gathering_state_;
 
   int check_receiving_interval_;
   int64_t last_ping_sent_ms_ = 0;
   int weak_ping_interval_ = WEAK_PING_INTERVAL;
   TransportChannelState state_ = TransportChannelState::STATE_INIT;
   IceConfig config_;
   int last_sent_packet_id_ = -1;  // -1 indicates no packet was sent before.
   bool started_pinging_ = false;
+  // Its value will be set in subsequent CLs based on signaling exchange.
+  bool peer_supports_renomination_ = false;
+  // The value put in the "nomination" attribute for the next nominated
+  // connection. A zero-value indicates the connection will not be nominated.
+  int nominating_value_ = 0;

[pthatcher1, 2016/07/28 22:57:25]

I'd prefer "nomination" over "nominating_value".  

And next_nomination_ would perhaps be a more clear name.

[honghaiz3, 2016/08/03 04:46:56]

I choose nomination_ because it is more consistent with use_candidate_attr.  

 
   RTC_DISALLOW_COPY_AND_ASSIGN(P2PTransportChannel);
 };
 
 }  // namespace cricket
 
 #endif  // WEBRTC_P2P_BASE_P2PTRANSPORTCHANNEL_H_