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

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Feb 2005 17:12:32 -0500

I'm OK with that.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Thursday, February 03, 2005 14:09
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'IETF MMUSIC WG'
> Subject: Re: [MMUSIC] ICE feature - TCP alternates for a UDP stream
> 
> 
> 
> 
> Francois Audet wrote:
> 
> >  > > I assume the RTP/TCP transport option will NOT be made 
> mandatory 
> > in  > > ICE?  >
> >  > No, in that we concluded that nothing in particular was
> >  > mandatory, not
> >  > even TURN/UDP. However I will add motivation text for this which
> >  > explains why it might be a good idea.
> > 
> > I think we should be a bit careful on what we say on RTP/TCP 
> > transport.
> > 
> > While I understand that it may make sense in some cases
> > to "recommend" using RTP/TCP if everything else fails.
> > 
> > However, there are environments where this may NOT make sense. For 
> > example, in an Enterprise, you may not want to allow RTP/TCP at all 
> > because of quality issues.
> > 
> > So I would say it needs some qualifiers along the lines of 
> "if RTP/TCP 
> > transport is acceptable for the application, it is recommended that 
> > bla bla bla".
> > 
> 
> Certainly I think it is reasonable to allow an endpoint to not even 
> offer RTP/TCP if that is appropriate for the environment.
> 
> The question is about whether an endpoint has to implement 
> it. THere, I 
> think its like TURN. We don't make it a MUST. We specify that 
> you SHOULD 
> implement something that provides media transport over TCP and I will 
> explain the motivations for why this is a good idea.
> 
> -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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 4 Feb 2005 17:28:43 -0500

OK. I understand. It would just need to be documented in more 
details.

> Sent: Friday, February 04, 2005 07:25
> inline.
> >  > My first inclination was that you would still use STUN 
> for the  > 
> > connectivity check over TCP; irregardless of whether that tcp  > is 
> > through  > a TURN relay or direct (indeed, the peer in the 
> call won't
> >  > normally even
> >  > know whether the tcp connection it will make is direct 
> or through a
> >  > relay). Recall that stun can run over tcp.
> > 
> > Hum. If we are to use STUN on TCP, I think we need to clarify in 
> > draft-ietf-behave-rfc3489bis how it works. There are a number of 
> > statements in there that sort of imply that it doesn't work 
> with TCP.
> 
> Binding allocation won't work, but you can send a request and get a 
> response. Remember that the shared secret allocation messages all run 
> over tcp.
> 
> > 
> > Are you saying that you would send the binding requests on TCP?
> 
> Yes, but they would do nothing more than checking liveness of the tcp 
> connection.
> 
> 
> > I would have tought that the connection itself would be sufficient, 
> > but maybe I'm missing some advantage that the STUN/TCP option would 
> > have.
> > 
> > Anything in mind?
> > 
> 
> I had in mind some bizarre cases where the connection does 
> get set up, 
> but somehow the nat discards state and data can't actually get 
> transmitted. Not sure this is worth worrying about.
> 
> -Jonathan R.
> 
> --