> -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of Thomas Gelf > Sent: Friday, 12 March 2010 3:33 PM > > All, > > wondering myself where I can find an RFC section stating how an UAC > shall behave, if it discovers itself being behing a symmetric NAT (as > of > RFC3489). Shall it fill Via, Contact and SDP with it's internal > IP:Port, > or shall it use it's reflective ip:port pair, even if knowing that it > will not be useful for anything (apart from "hiding" internal IPs)? > > I would opt for the former, as this would allow NAT-aware proxies (or > those braindead devices calling themselves ALG) to easily help him. In > the latter case a proxy would still be able to discover that the UAC > needs "some assistance" by comparing source ip:port with what is > written > in it's Via/Contact headers, but this alone would usually not help > against location databases filling up with registrations using many > different Contact's. > > Unfortunately out in the wild I've met both behaviours. I would really > like to try explaining some vendor what they are doing wrong - however > I > did not find anything "proving" what the correct behaviour would be in > this case. > > Can anyone give me a little hint?
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. 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. 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. As far as consistency wrt SIP NAT handling in the wild there isn't any. Aaron _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
