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.