Subject: [MMUSIC] ICE-tcp draft updated

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Mar 2006 13:11:21 -0500

I've submitted a revised version of the ice-tcp draft, now a WG item. It 
should appear in the archives shortly. Until it does, you can pick it up 
here:

http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-tcp-00.txt

The draft has had some substantial changes to accomodate the main 
comment made from the last meeting - the desire to support simultaneous 
opens. The previous design was built around the assumption that you 
didnt do this, and a bunch of stuff didnt work when I looked into how to 
make it happen.

The good news is, the current draft allows it, in addition to more 
traditional one-side-active attempts, and indeed, has the agents try 
both (simultaneous opens is higher priority). The draft also defines how 
one uses TCP addresses learned from a stun server (now called 'server 
reflexive transport addresses', which you will see defined in the 
substantially overhauled stun doc).

The draft also now allows tcp active connection attempts to be made 
through a TURN server, using the new TURN Connect request.

I have also made the change to the main ICE spec allowing a validated 
candidate to be used for media prior to its appearance in an 
offer/answer. This mechanism works for tcp too, so that, with ice-tcp, 
you can do an offer/answer exchange, ICE will try to get a connection 
set up, and once one is established, you can begin using it immediately 
for application traffic, like RTP. The draft steps through how to use 
draft-ietf-rtp-avt-contrans to demux both stun and rtp (necessary for 
this optimization to work with tcp), and provides a generalized 
algorirhtm for stun and application demux on any framing protocol over 
tcp, as long as it has a single property (which i think is almost always 
true).

I'm still polishing the main ice spec, so you'll see that just around 
deadline time. Its biggest change was this trick to send media prior to 
the next offer/answer, and beyond that, a big terminology overhaul that 
is a consequence of the usage of turn to obtain both a relayed address 
and the address on the public side of the nat (server reflexive address).

The good news of all of this is that ICE-tcp now, I believe, will allow 
for p2p tcp connections in lots of cases, and fall back to turn tcp 
relays only when that doesn't work.

There are no open issues with the ice-tcp draft AFAIK. THe main thing it 
needs now are reviews, and in particular, behave folks who are experts 
in the way things work with simultaneous tcp opens through NAT, to 
verify that all of this works. I checked a few cases, but more eyeballs 
are needed.

Thanks,
Jonathan R.

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

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic