TURN does not work about uproxy-p2p HOT 7 CLOSED

Comment by myleshorton from Wed Oct 16 05:34:53 2013

TURN is a STUN extension, so TURN messages are STUN messages. Possible Wireshark is labeling them as STUN messages correctly when in fact they're being used for TURN?

from uproxy-p2p.

Comment by ryscheng from Wed Oct 16 05:38:14 2013

TURN servers are still separate servers and handled differently. There's an authentication stage and other sorts of complexity that WebRTC needs to handle properly to make sure it works. Wireshark definitely labels everything STUN so we're not missing messages, it just never gets to the TURN stage when STUN fails.

from uproxy-p2p.

Comment by ryscheng from Wed Oct 16 05:39:00 2013

This is possible a TURN for DataChannels on Mac OS X (Chrome beta). We should try 2 Linux machines with UProxy and https://www.cubeslam.com/raonul

from uproxy-p2p.

Per Trevor:
So, Chrome will only use TURN if you specify a TURN server in your config when creating the peer connection, e.g.:

var stun = {
  'url': 'stun:stun.l.google.com:19302'
};

var turn = {
  'url': 'turn:SOMEHOSTNAME:3478',
  'username': 'test',
  'credential': 'test'
};

var pc_config = {
  'iceServers': [ stun, turn ]
};

Right now, our transport provider doesn't do this so we're just not using TURN.

from uproxy-p2p.

This is: freedomjs/freedom#10

from uproxy-p2p.

Probably needs to work with the new churn repo.

from uproxy-p2p.

Dup of #191

from uproxy-p2p.