Cast Port Allocator Factory for PeerConnection

remoting/jingle_glue/chromium_socket_factory.cc

Index: remoting/jingle_glue/chromium_socket_factory.cc
diff --git a/remoting/jingle_glue/chromium_socket_factory.cc b/remoting/jingle_glue/chromium_socket_factory.cc
index 09e45f4519ca0730343ceffa65e0bf3d11deaf7f..7060b186eaaf9a5a3856423bddd7edb2fbb1b2e1 100644
--- a/remoting/jingle_glue/chromium_socket_factory.cc
+++ b/remoting/jingle_glue/chromium_socket_factory.cc
@@ -371,7 +371,7 @@ ChromiumPacketSocketFactory::CreateServerTcpSocket(
     int min_port, int max_port,
     int opts) {
   // We don't use TCP sockets for remoting connections.
-  NOTREACHED();
+  // NOTREACHED();

[aiguha, 2014/07/17 03:11:36]

There seems to be no way to restrict WebRTC from trying to use TCP. Thus, when
performing its ICE establishment, it still tries to call this method and hits
the NOTREACHED.
TODO(aiguha): Find a better way to deal with this, as this is likely not
acceptable.

[Sergey Ulanov, 2014/07/17 18:54:40]

I think what might be happening is that the peer (i.e. browser) always allocates
TCP candidates and PeerConnection tries to use them even when TCP is disabled,
i.e. flags disabled only allocation of TCP candidates (i.e.
CreateClientTcpSocket() is never called), but incoming TCP candidates are still
used.

The reason we disable TCP for regular Chromoting connections is because
PseudoTCP performs poorly over TCP. But that reason doesn't apply when casting
the screen using WebRTC, so we actually may want to enable TCP at some point.

I suggest you replace NOTREACHED() with NOTIMPLEMENTED().

[aiguha, 2014/07/17 19:39:59]

Done.

[aiguha, 2014/07/17 19:39:59]

You're right, I think that's exactly what's happening. 

Understood. I'll go ahead and replace it with NOTIMPLEMENTED() for now then. 

   return NULL;
 }