>
> Usage:
>> $ curl --turn [IP:port] --proxy-user [user:pass] [destination]
>>
>
> Do you think it makes sense to also support some sort of proxy protocol
> prefix? Like for example setting the proxy to "turn://IP:port" in the same
> vein we can do SOCKS and HTTP etc already. It makes it way simpler for
> applications that want to pass on or set "a proxy".
>

Yes, actually it does support that, I just forgot to mention.

You can use:

$ curl --turn [IP:port] --proxy-user [user:pass] [destination]

or

$ curl --proxy turn://[user:pass]@[IP:port] [destination]

As usual.

Is there perhaps any other existing clients/browsers that support TURN that
> we can learn or adapt config ways from?

Definitely not, and people tend to bite when you mention this :)

That's why I classified it as experimental. I wanted something like this
while testing some TURN servers with support to TCP: I just wanted to do
some "real life" data requests (and load tests) in order to verify their
robustness and stability.

But in the real life usage, it can be used only for overlay networks, like
to avoid eavesdropping and bypassing Internet connections subjected to
censorship.

- It doesn't support short term passwords (only no-auth and long-term-auth
>> at this time);
>>
>
> For someone not really versed in the details of the protocol, what's the
> actual protocol differences between short term and long term auth?

A short term password is normally obtained by connecting to some other
Internet service, sending the long term credentials, and obtaining a
user/pass tuple for using in a very short time for traversing the
firewall/blocking. The old TURN RFC used a special TUN request for this
(the SHARED SECRET request), but it has been deprecated. Nowadays
implementations tend to use a combination of HTTP and JSON, but the
standards are still new in the sense that servers are not 100% compatible
at the moment.

Long term passwords are set up on the TURN server, and then used by all
clients. That's the main difference.

> - Currently it doesn't support FTP in PASV mode, but should work fine
>> with any other protocol over TURN since one doesn't use a secondary socket;
>>
>
> If you make it like the socks proxy approach, can't you just add a
> function call in ftp.c:proxy_magic() then to make PASV work?

The problem is that TCP over TURN requires two sockets: one for control,
another for actual data. The control socket was selected as being the
FIRSTSOCKET, and the data socket the SECONDARYSOCKET. Then, the current
implementation fails miserably if a protocol tries to call Curl_TURN
passing SECONDARYSOCKET as the sockindex parameter.

That approach of course can be solved by extending the connectdata
structure, but I decided to keep it as simple as possible at this stage, as
I really don't think that cURL over TURN will be used by a lot of people.
Or, at least, not at this moment.

Regards,

--
Guilherme Balena Versiani

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-08-26