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

From: "Francois Audet" <[email-masked]>
Date: Tue, 1 Feb 2005 19:46:45 -0500

So you are saying that the media would be transported over RTP/TCP
to the TURN relay, and then to the other endpoint using another RTP/TCP
session, right?

And not and end-to-end RTP/TCP session between the two peers, right?

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Thursday, January 27, 2005 10:43
> To: IETF MMUSIC WG
> Subject: [MMUSIC] ICE feature - TCP alternates for a UDP stream
> 
> 
> 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
> 
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Feb 2005 01:45:35 -0500

> to the TURN relay, and then to the other endpoint using another RTP/TCP

Yes.

> And not and end-to-end RTP/TCP session between the two peers, right?

One could offer that up as an additional alternate, yes. In other words, 
just like the client would offer UDP alternates learned from STUN, TURN 
and local interfaces, so too they could offer TCP alternates learned 
from TURN and local interfaces. The latter, if it works, would result in 
a direct TCP connection from one user to the other. The former would end 
up with clients connecting through the TURN server.

-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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 14 Feb 2005 17:41:27 -0800

I think I am a little lost. RTP over TCP seems ok for streaming media but a
really bad idea for interactive (ie low latency media). However ICE is
primarily for where two clients want to connect which I generally think of a
interactive media.

Do we have a use case where we want to do streaming media between two
clients where ICE would be appropriate or are we thinking of this being used
with interactive media?

Cullen

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Feb 2005 09:20:25 +0100

Hi Cullen,

I can at least answer that having streaming between arbitrary placed 
servers and clients is a valid use case. Think, home surveillance camera 
and you end up with a potentially NATed and FWed streaming server.

Cheers

Magnus

Cullen Jennings wrote:
> I think I am a little lost. RTP over TCP seems ok for streaming media but a really bad idea for interactive (ie low latency media). However ICE is primarily for where two clients want to connect which I generally think of a interactive media.
> 
> Do we have a use case where we want to do streaming media between two clients where ICE would be appropriate or are we thinking of this being used with interactive media?
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]