Subject: [Ietf-behave] TURN Issue #3: TCP to UDP allocations

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Dec 2005 08:24:25 -0800 (PST)

TURN currently provides TCP allocations and UDP allocations. You can 
open a TCP connection to the sevrer and get a TCP port, and you can open 
a "UDP connection" to the server and get a UDP port. However, you cannot 
open a TCP connection to the server and get a UDP port allocated. Such a 
capability would require the TURN server to apply framing (such as the 
AVT contrans spec) to push UDP contents over a TCP connection.

The benefit to this kind of approach is that it allows for partial UDP 
transport in situations where one side is behind a nasty symmetric nat 
or direwall (and thus must have tcp), whereas the other side has UDP 
connectivity. I've spoken to several people who have deployed voip 
configurations with this split UDP/TCP RTP transport, and claim it is 
better than all TCP.

I think this is a good idea and we should do it. There are three options 
here:

1. No, don't allow this.

2. Yes, allow this, but do it via an extension to TURN, rather than in 
the core spec.

3. Yes, allow it by adding some attributes to the core spec.

My proposal is option 2.

Comments?

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Saikat Guha <[email-masked]>
Date: Tue, 6 Dec 2005 01:41:14 -0800 (PST)

On Mon, 2005-12-05 at 11:24 -0500, Jonathan Rosenberg wrote:
> However, you cannot 
> open a TCP connection to the server and get a UDP port allocated. 
> [...]
> 
> 1. No, don't allow this.
> 

FWIW, when NAT traversal in Skype fails, it falls back onto a TURN-like
relay server, which bridges UDP and TCP. I have data that shows that
this functionality is invoked often (I can get numbers if people think
thats useful).

So my vote is either option 2 or 3.

-- 
Saikat
Attachment:
signature.asc

---

From: Jason Fischl <[email-masked]>
Date: Tue, 6 Dec 2005 08:11:03 -0800 (PST)

> > 3. Yes, allow it by adding some attributes to the core spec.
My vote is 3.

> this functionality is invoked often (I can get numbers if people think
Yes. Please provide any stats that you might have.

---

From: "Derek MacDonald" <[email-masked]>
Date: Tue, 6 Dec 2005 11:01:53 -0800 (PST)

I vote #3.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jonathan Rosenberg
> Sent: Monday, December 05, 2005 8:24 AM
> To: Behave
> Subject: [Ietf-behave] TURN Issue #3: TCP to UDP allocations
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Dec 2005 09:38:11 -0800 (PST)

There were only a few responses here, but seems like general support was 
to have this functionality, with a preference for putting it in the core 
spec. I'll do that.

As a note - there are some complications in this. The TURN server has to 
do some additional work when taking UDP packets and shoving them over a 
TCP connection. It needs to frame them. This requires awareness of the 
protocols ontop of TCP. What I plan on doing is having an additional 
parameter of the Allocate verb, which indicates the framing algorithm 
for UDP to TCP encapsulation/de-capsulation. Initially, only one value 
would be supported, the one defined in 
draft-ietf-avt-rtp-framing-contrans-06.txt, but others could be signaled 
should they arise later.

-Jonathan R.

Derek MacDonald wrote:

I vote #3.

-----Original Message-----

My proposal is option 2.

Comments?

-Jonathan R.