Subject: [Ietf-behave] updated

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 26 Jun 2006 02:38:31 -0700 (PDT)

Hi Folks,

I just submitted a significant revision of TURN.  Until it appears in
the archive, you can find it here:
http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-turn-01.txt
http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-turn-01.html
While there are some major changes, the draft still has several open
issues and will need another heavy editing pass. The highlights:
1) Disallowed relaying UDP between the client and server to TCP
between the server and the peer.
2) Added lightweight TCP framing and simplified rules for wrapping UDP
with a magic cookie in Data or Send indiciations.
3) Removed the Connect Request.  This did not make sense.  If the peer
could accept an inbound TCP connection, the client could probably just
open its connection directly to the peer.
4) Reintroduced the concept of a door.  The TURN server will accept a
connection to the door once, establishes a binding, an then no further
requests are allowed unless there is an explicit permission.
5) Added Connection Status Indication, so you can tell if the TCP
connection from the relay to the peer dies.
6) Added ability to move/refresh your allocation to a new source address/port.

7) Hopefully clearer Overview section.

8) Added more motivation for odd/even port alignment

9) Got rid of DESTINATION-ADDRESS.  REMOTE-ADDRESS is now used in its place.

10) Use XOR-MAPPED-ADDRESS consistently instead of MAPPED-ADDRESS

11) I added explicit Open Binding and Close Binding requests for completeness

Selected OPEN ISSUES:
A) Can we get rid of the state machine for Set Active Destination?
(See proposal in the draft)
B) Do we want Open/Close Binding?

C) Is it OK if clients have to use STUN messages to keep allocations
alive?  (Data used to keep them alive).
ok, enough for now.

thanks,
-rohan

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 26 Jun 2006 03:46:41 -0700 (PDT)

> (See proposal in the draft)

Is there any reason to actually not always encapsulate TURN client-to-server 
packets? For sure, it would add extra on-the-wire overhead in the case of 
non-encapsulated data, but it would also simplify implementations further, 
and kill the need for the magic cookie.

> alive?  (Data used to keep them alive).

This might add the requirement that client implementations run a 
TURN-dedicated thread/timer to keep sending refresh packets in the 
background, unless something else already requires such a thing (does it 
bother anyone?). I agree that this simplifies and cleans up things, though.

-- 
Rémi Denis-Courmont