Only try to pair protocol matching candidates for creating connections.

webrtc/p2p/base/p2ptransportchannel.cc

Index: webrtc/p2p/base/p2ptransportchannel.cc
diff --git a/webrtc/p2p/base/p2ptransportchannel.cc b/webrtc/p2p/base/p2ptransportchannel.cc
index da8b5f76c2f7b85d6684975f1c66881fec25e2f0..dfa8b00373738952a73b5966604111022ee62378 100644
--- a/webrtc/p2p/base/p2ptransportchannel.cc
+++ b/webrtc/p2p/base/p2ptransportchannel.cc
@@ -738,6 +738,9 @@ bool P2PTransportChannel::CreateConnections(const Candidate& remote_candidate,
 bool P2PTransportChannel::CreateConnection(PortInterface* port,
                                            const Candidate& remote_candidate,
                                            PortInterface* origin_port) {
+  if (!port->ProtocolMatch(remote_candidate.protocol())) {
+    return false;
+  }
   // Look for an existing connection with this remote address.  If one is not
   // found, then we can create a new connection for this address.
   Connection* connection = port->GetConnection(remote_candidate.address());

[pthatcher1, 2015/12/11 02:05:36]

So, if we get two TURN candidates, one for TCP and one for UDP, both with the
same IP and port, what happens?  It's the same TurnPort, right?  So wouldn't
that case fail?  Would that mean we'd be back to making the map be based on (ip,
port, protocol)?  

[honghaiz3, 2015/12/11 18:36:31]

TurnPort should only generate UDP candidate. GTurnPort may handle both UDP and
TCP connections but that is deprecated, right?

[pthatcher1, 2015/12/12 03:05:30]

Oh, duh.  Good point.