> -----Original Message----- > From: Thomas Gelf [mailto:[email protected]] > Sent: Monday, 15 March 2010 12:58 PM > To: Aaron Clauson > Cc: [email protected] > Subject: Re: UAC behaviour if symmetric NAT is detected > > > Aaron Clauson wrote: > > It's better that a user agent do as you opted and leave its private > IP > > address and port in the SIP headers and let the SIP server cope with > it. > > Is there any written reference stating that this would be the preferred > behaviour for clients sitting behind a symmetric NAT?
Well RFC3261 implicitly says that's the way to deal with all NATs since it chose to ignore them altogether :-). > > In probably 90% of cases, where NATs preserve the port, the SIP > server can > > deal with the NAT very simply without resorting to the mechanisms in > the > > two documents mentioned above which are getting more and more > onerous, > > shame it couldn't have stayed at the original STUN document of > > RFC3489. > > 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. ICE (which is STUNv2 and TURN) may be better at handling NATs but it requires TURN for the cases that STUNv1 couldn't handle and TURN isn't a signalling solution. In my humble opinion if proxying media is the answer why not just multiplex the media and the signalling in the first place, aka IAX & Skype, and avoid the need to implement ICE (yes multiplexing means scalability suffers but so does TURN). I always find these sorts of discussion ironic, ALGs were introduced to help SIP deal with NAT but because they generally make such a mess of things they are now one of the reasons to introduce ICE, a fix for a fix for a fix; RFC3261 not handling NAT being fixed by ALGs being fixed by ICE. I appreciate it's a somewhat philosophical debate and doesn't answer your original question so I'll stop while I've only put one foot in it. Aaron _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
