Add disabled certificate check support to IceServer PeerConnection API.

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 71 matching lines @@
 // TODO(ronghuawu): Use "host", "srflx", "prflx" and "relay". But this requires
 // the signaling part be updated correspondingly as well.
 const char LOCAL_PORT_TYPE[] = "local";
 const char STUN_PORT_TYPE[] = "stun";
 const char PRFLX_PORT_TYPE[] = "prflx";
 const char RELAY_PORT_TYPE[] = "relay";
 
 const char UDP_PROTOCOL_NAME[] = "udp";
 const char TCP_PROTOCOL_NAME[] = "tcp";
 const char SSLTCP_PROTOCOL_NAME[] = "ssltcp";
+const char TLS_PROTOCOL_NAME[] = "tls";
 
-static const char* const PROTO_NAMES[] = { UDP_PROTOCOL_NAME,
-                                           TCP_PROTOCOL_NAME,
-                                           SSLTCP_PROTOCOL_NAME };
+static const char* const PROTO_NAMES[] = {UDP_PROTOCOL_NAME, TCP_PROTOCOL_NAME,
+                                          SSLTCP_PROTOCOL_NAME,
+                                          TLS_PROTOCOL_NAME};

[pthatcher1, 2016/12/07 21:29:35]

We should probably document what these things mean.  First, that they are used
for ICE candidate protocol and ICE candidate relay protocol.  UDP and TCP are
clear.  SSLTCP means to use a "fake SSL" connection over TCP (see
AsyncSSLSocket).  This new thing (TLS) is real TLS over TCP.  But it's only used
by the ICE candidate relay protocol, not ICE candidate protocol.  In other
words, we have it implemented in turnport.cc, but not tcpport.cc.

[Taylor Brandstetter, 2016/12/08 01:36:40]

I agree about documenting what these things mean. But we should document how
they're used in the places they're used, separately.

[hnsl1, 2016/12/12 16:08:13]

I agree there are different meanings here that should be documented and possibly
cleaned up. If tcpport ends up having some other meaning of "tls" it can fork
the ProtocolType type into a new type. For now this should not affect tcpport
since SupportsProtocol() will return false for "tls" candidates. But I think
this cleanup and documentation can be added in a future CL. The different
meanings where already there before this CL (candidate protocol vs relay client
protocol).

 
 const char* ProtoToString(ProtocolType proto) {
   return PROTO_NAMES[proto];
 }
 
 bool StringToProto(const char* value, ProtocolType* proto) {
   for (size_t i = 0; i <= PROTO_LAST; ++i) {
     if (_stricmp(PROTO_NAMES[i], value) == 0) {
       *proto = static_cast<ProtocolType>(i);
       return true;
@@ skipping 1465 matching lines @@
     ASSERT(sent < 0);
     error_ = port_->GetError();
     stats_.sent_discarded_packets++;
   } else {
     send_rate_tracker_.AddSamples(sent);
   }
   return sent;
 }
 
 }  // namespace cricket