Aaron Clauson wrote: > ICE (http://tools.ietf.org/html/draft-ietf-mmusic-ice-19) and STUN > (http://tools.ietf.org/html/rfc3265) are the two documents I know of that > attempt to help SIP agents cope with NAT. In my own opinion the proposals in > these documents are making a bad situation worse.
I do not fully agree on this. While you may be right on STUN (RFC 3489), in my believes ICE is very well done and definitively the way to go. > 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? > 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. > As far as consistency wrt SIP NAT handling in the wild there isn't any. That brings me back to my initial question: while STUN is not a solution (and ICE will hopefully lead us to a better world), it at least helps to solve some issues. It solves NAT issues for all Cone NAT types (at least unless you have two devices sitting behind the very same NAT device lacking hairpin support). But, in my humble opinion, it should NOT try to do anything "intelligent" once it detects being behind a symmetric NAT. So, once again, the question is: is there really no document stating how an UAC, that detected itself being behind a symmetric NAT, shall behave? Stating that it SHOULD NOT or MUST NOT write useless reflected information to SIP header and SDP body? Thank you for your support! Regards, Thomas Gelf -- mail: tho...@gelf.net web: http://thomas.gelf.net/
_______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
