Ideally, the network between components in a distributed application is like glass: perfectly transparent. The end-to-end argument suggests two characteristics that the ideal network must exhibit: a single universal addressing scheme and open communication.
A single, universal addressing scheme implies that application components can distinctly identify other application components on the network. Open communication implies that an application can connect to and start a conversation with any other application on the network for which it knows the address. NAT destroys both of these characteristics.
Many people advocate solutions to be placed at the service provider facility to support SIP devices behind NAT gateways. These solutions attempt to discover NAT and insert themselves into the SIP signalling path (and in some cases the media path). They work in cooperation with, and in addition to, the service provider’s core SIP infrastructure. These solutions are not elegant. There is no explicit standard for performing the NAT detection and the various translations of the SIP traffic. They also violate the peer-to-peer nature of SIP, in some cases causing all media traffic to flow through the NAT translation gateway on the service provider’s network.
I have spent a long time becoming comfortable with SIP and NAT technology and I am convinced that network facility-based solutions are a dead end. They can never be made to reliably detect the conditions for which their NAT helping functions should be invoked. As a result, they can corrupt valid (functioning) SIP signaling causing calls that do not need any NAT corrections to fail because of inappropriately applied facility-based NAT “fix-ups”.
In the end, facility-based solutions may correct some portion of calls while damaging others. As SIP end-points become more sophisticated in their support for NAT traversal, the percentage of cases where they actually induce problems will only increase.
I now have come to firmly believe that NAT problems should be solved at the edge. Correct the problem as close to the source of the problem (the NAT gateway itself) as possible, so that by the time the SIP proxy and SIP core sees the SIP signaling, it has already been repaired. It is more reliable, more efficient, and can be done at a much lower cost than network-based NAT helpers.
This, of course, should be obvious to any STUPID Network adherents.
Probably UPnP (at least in the context of consumer application scenario) can be used to address this problem. Most of the home routers and many SIP clients seem to support it.)
I’m not an expert but i think you might be right.