Subject: [MMUSIC] ICE feature - TCP alternates for a UDP stream

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Jan 2005 13:42:35 -0500

Folks,

In the past, we had considered whether or not to also apply ICE to allow 
a TCP session to be an alternate for a UDP one. We decided to keep the 
scope narrow, and not consider this.

However, in reality, I think there is an extremely pressing need for 
this. In particular, there are many deployments where we would like to 
support SIP, but (for better or for worse), networks are only allowing 
outbound TCP connections. This is not a NAT issue so much as a firewall 
issue, but in this case the firewall is introducing a connectivity 
problem of the sort that ICE was designed to address. As such, I think 
its in scope. If we defer this to a future document, I fear we will get 
implementations missing this feature and thus SIP/ICE clients will find 
themselves in situations where it STILL doesnt "just work", despite the 
fact that ICE is supposed to make it "just work".

Now, all of us agree, no doubt, that RTP over UDP is far preferable to 
RTP over TCP, but if TCP is all you can get working, TCP is better than 
nothing. ICE can serve a crucial role of figuring out, dynamically, 
whether or not UDP can be made to work, and thus whether the lower 
priority alternative of TCP, should be used.

So, here's how it would work. A client would include UDP local 
addresses, STUn derived addresses, TURN derived (using UDP), and ALSO 
TURN derived using TCP (recall that TURN supports TCP connections). We 
have a spec for RTP over TCP (draft-ietf-avt-rtp-framing-contrans), 
which makes use of the comedia spec. The client would specify that it is 
passive. The INVITE is sent. The peer connects to this (indicating that 
it is active in its answer); that connection terminates on the TURN 
relay used by the caller. The peer, as with any other session, uses STUN 
to check connectivity. The caller can then use STUN itself to verify 
connectivity in its direction (presumably it would always work in both 
directions).

The nice thing is, by setting the priorities appropriately, this 
connection would only get used if the other UDP choices fail. That gives 
us even further robustness.

Presumably this could also work for TLS, in which case the TURN server 
would terminate the TLS connection from the caller and from the callee.

Specifying this isn't really hard. The main issue is just a grouping 
one. We need to be able to apply the comedia parameters to candidates. 
You can't just include them under the m-line, since then you don't know 
to what they apply. In any case, we don't really need or even want a 
generic grouping framework here; I would HATE for this to be used as an 
alternative for negotiating codec parameters in yet another way. As 
such, I would suggest merely extending the candidate line to include the 
transports and comedia information when needed.

Comments?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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