Re: updated TURN draft

Se-Chang Son <[email protected]> Wed, 05 Oct 2005 11:33:47 -0500
Newsgroups gmane.ietf.midcom
Message-ID <[email protected]>
Hi all,

Since I am a newbie to TURN and it seems that no one has answered Remi's 
question below, could someone explain me how a ftp will work with TURN?
If somebody can explain how TURN supports the following scenario, she/he 
will be very appreciated.

(1) ftp client behind a NAT (i.e. TURN client) makes ftp connection 
(control connection) to a ftp server in the public network (i.e. 
external client).
(2) several ftp commands are exchanged between them
(3) ftp client calls "put a_file" in the passive mode. In other words, 
the data connection is made from the ftp server to the ftp client but 
the data is transfered in the opposite direction.

The draft says that TURN has the same effect of having address 
restricted NAT. With such type of NAT, I think the above scenario must 
be possible.

Thank you.

Remi Denis-Courmont wrote:
> 	Hello again,
> 
> I don't understand how TURN clients could receive incoming TCP
> connections with the new draft 08. Maybe I'm getting it wrong.
> 
> According to the draft, if a TCP connection is received by the TURN
> server before the TURN client made a Send Request, the connection is
> rejected. However, if the TURN client makes a Send Request before the
> TURN server receives the TCP connection, then the TURN server will try
> to establish the connection actively, instead of waiting for an incoming
> connection from the specified host.
> 
> It sounds like a vicious circle. In particular, I wonder how two TURN
> clients could establish a TCP connection between themselves with the new
> scheme.
> 
> As a side note, I'm doubtful about the use of TURN server to relay
> active TCP connections. Such connections should go through NATs without
> the help of a TURN server, and as such, not using the TURN server would
> save TURN server's bandwidth.
> 
> There doesn't even seem to be the advantage of knowing the external
> source (IP, port) tuple given the TURN server doesn't tell the TURN
> client about the used "eph[me]eral port" that it has used.
> 
> Regards,
>