Subject: [BEHAVE] connect request in draft-ietf-behave-turn-03.txt

From: "Adam Fisk" <[email-masked]>
Date: Fri, 8 Jun 2007 16:19:55 -0400

I'm unclear why the TURN server is expected to attempt to open up a TCP
connection to the remote host when it receives a connect request.  If the
TURN server is able to successfully make the connection to the remote host,
why in the world would the client be using TURN in the first place?  Why
wouldn't the client just bypass the costly relay and make the direct
connection?  Is this for highly controlled networks where clients may only
have outgoing access to the TURN server and not the remote host?

I can understand the allocating of permissions in response to a connect
request.  As such, it would make more sense to me that the connect request
be a "permission request" where no outgoing connection attempt is made.  As
far as I can tell, that outgoing connection attempt is a waste of precious
server resources in the vast majority of cases because it will almost always
fail.

Am I missing something?

Thanks.

-Adam Fisk
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 11 Jun 2007 09:56:46 +0300

On Friday 08 June 2007 23:19:55 ext Adam Fisk wrote:
> why in the world would the client be using TURN in the first place?

The other side could be using TURN too. If TURN servers were not capable of 
actively connecting, there'd be a dead-lock.

> Why wouldn't the client just bypass the costly relay and make the direct
> connection?

If the either side does not implement ICE-TCP, it is typically not possible to 
negociate this properly; TURN becomes the only catch-all connectivity 
solution.

This is particularly true when you act as the offerer, know that active 
connections to you might not work, and have no idea what the answerer 
situation is.

Or then we need to specify that the answerer must not use TURN when the 
offerer does (or more generally when the offerer can be connected to).

But then...

> Is this for highly controlled networks where clients may only

...that would still be a problem.

-- 
Rémi Denis-Courmont