On Mon, Jan 25, 2016 at 5:55 PM, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
I'm connected using dual-stack IPv4 and IPv6, but I'm not sure if that's the issue.
[snip] 2016/01/26 12:23:21 Sending offer via meek channel... Target URL: https://snowflake-reg.appspot.com/ Front URL: www.google.com 2016/01/26 12:23:25 MeekChannel Response: 200 OK
2016/01/26 12:23:25 Received Answer: [snip]
Since the offer & answer exchanged successfully, I'm fairly certain this failed during ICE negotiation. In most cases, the public ip candidates given by STUN servers are sufficient for peers to negotiate a working p2p path. But sometimes, maybe 14% of the time [1], this isn't enough -- usually due to symmetric NAT / lack of port preservation, and a TURN relay is required as a last resort.
I haven't yet configured TURN in either the client or the proxy, so this seems the most likely cause. I can update that to see if it works for you. We should probably setup some sort of Snowflake test suite for various NAT topologies...
Later on, this may mean more complications for that fraction of users (TURN relays could get blocked in filtered zones). We do have some plan to inform clients of temporary TURN servers through the domain fronted signalling channel eventually, which may help. Also, once snowflake proxies & clients are multiplexed, perhaps the likelihood that TURN continuous to be absolutely required for every pair of peers greatly decreases and we might be fine again. More thought is needed here.
[1] old numbers from http://webrtcstats.com