> -----Original Message----- > From: Iñaki Baz Castillo [mailto:i...@aliax.net] > Sent: Monday, 15 March 2010 2:57 PM > > AFAIK TURN is just required in case both endpoints are behind > different symmetric NAT routers. IMHO there is enough cases in which > this doesn't happen so ICE is really *suitable*.
That's also my understanding of the problem TURN seeks to solve. > >In my humble opinion if proxying media is the answer > > Proxing the media is NOT the anwser. I agree entirely that's why I find the TURN (which does proxy the media) so against the grain. > > > why not just multiplex the media and the signalling in the first place, aka > > IAX & Skype, > > Is IAX a good protocol? Does Skype *always* force the media relay > through a media tunnel? > > The response to both questions is "NO" so not sure what you meant > saying that. Again maybe so, although you'd certainly get an argument on the IAX front in certain quarters especially when talking in a NAT context. However my point was that compared to a SIP + TURN you would have less moving parts if the SIP + RTP were multiplexed. In my opinion neither proxying or multiplexing media are good solutions. > > > ICE, a fix for a fix for a fix; RFC3261 not handling > > NAT being fixed by ALGs being fixed by ICE. > > I don't understand this point. ALG breaks, in most of the cases, the > SIP signalling [*]. > STUN, ICE or server solutions don't help here as in many cases those > kind of SIP ALG routers modify and break the signalling even if the > SIP messages contain public addresses (due to STUN usage), so I don't > think ICE is here to fix ALG's. ALG's just must dissapear ASAP. I agree entirely that ALG's are bad and should disappear. My point was related to Thomas Gelf's paragraph that I inferred ICE was being stated as a solution to ALG's. Perhaps I inferred incorrectly but it seems a moot point since the consensus is that ALG's are evil. > From: Thomas Gelf [mailto:tho...@gelf.net] > Once again, I must disagree. RFC 3489 wasn't able to handle various > issues. Also it was unable to distinguish between NAT and filtering > type. It was unable to detect hairpin support and ALGs. ICE shows how > the STUN protocol can be used in a very effective and wise way. It's completely off the OP's original question and I have already promised to leave his question alone but I just can't resist one more ill-conceived notion. My solution to symmetric NATs would be the same as the one for ALG's make them disappear. Most SIP calls are between a client behind NAT and a provider server on the internet. If a SIP end user finds they need to make SIP calls to another end user directly and symmetric NAT prevents them then they could replace their router with a proper non-symmetric NAT one; routers are cheap. Yes it means pain for users which is to be avoided as much as possible but in this case it's better than adding another layer to the house of cards: IPv4 address shortage leads to NAT; SIP (RFC3261) doesn't accommodate NAT; SIP enhancements and add-ons such as rport and STUN don't accommodate symmetric NAT; TURN solves symmetric NAT but introduces an extra network element on the media path along with its associated scalability, reliability, security etc. concerns. The root cause of the need for TURN is the IPv4 address shortage and that problem has a good solution; replacing IPv4 with IPv6. An end user replacing their router with one that does not use symmetric NAT and that supports IPv6 would solve any current NAT related SIP issues and them a the option of a future path to get rid of NAT completely when IPv6 is available and all without relying on a solution built on a house of cards. Aaron _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
