I agree with Andres, it is cheaper to invest in hardware than customer service... However, the nat_uac_test("16") will detect many faulty ALGs and STUN behind symmetric NAT because even though the SIP message seems to be with public IPs, the port in the via will not match the received port. Of course, there will still be ALGs that manages to replace contact and via with the correct port (and SDP with correct IP), but still manages to mess up SDP ports.
I have found Delta Three's document on NAT to be one of the best written on the various types of NAT and solutions to solve it: http://corp.deltathree.com/technology/networkaddress.asp
g-)
Andres wrote:
This is a lot more complex than it sounds, I know, but I think if I have more data to work with, I might be able to come up with a more acceptable scenario than we currently employ.
We too tried to use STUN as often as possible with all our users. Its fine at the beginning because you can fine tune everybody when you have a small customer base. As our network grew we found ourselves taking in more and more customer support calls from clients using STUN. The most common problem one had to deal with was that of NO Audio with customers changing routers from simple 'cone NAT' to 'symmetric NAT' type which of course breaks STUN. In the end we found it a lot more economical to pay for more bandwidth and use multiple RTP Proxy servers than to pay for more Tech Support people. It has worked out beautifully. I can't remember that last support call we ever had from somebody complaining about no audio. It had to be more that 2 years ago.