From SIPfoundry sipXecs IP PBX, The Open Source SIP PBX for Linux - Calivia

Problem Statement

NAT & firewall traversal issues remain the signle biggest obstacle when it comes to ubiquitous adoption of SIP as the standard protocol for real-time communications. Why is that? And why have the guys at the IETF not thought about this way before they introduced SIP?

From: Audet & Jennings, NAT UDP Unicast Requirements, IETF Draft, September 2005

   Network Address Translators (NATs) are well known to cause very
   significant problems with applications that carry IP addresses in the
   payload.  Applications that suffer from this problem
   include Voice Over IP and Multimedia Over IP (e.g., SIP and
   H.323), as well as online gaming.

   Many techniques are used to attempt to make realtime multimedia
   applications, online games, and other applications work across NATs.
   Application Level Gateways are one such mechanism.  STUN
   describes a UNilateral Self-Address Translation (UNSAF) mechanism.
   UDP Relays have also been used to enable applications across
   NATs, but these are generally seen as a solution of last resort.  ICE
   describes a methodology for using many of these techniques and
   avoiding a UDP Relay unless the type of NAT is such that it forces
   the use of such a UDP Relay.

   As pointed out, "From observations of deployed
   networks, it is clear that different NAT box implementations vary
   widely in terms of how they handle different traffic and addressing
   cases."  This wide degree of variability is one factor in the overall
   brittleness introduced by NATs and makes it extremely difficult to
   predict how any given protocol will behave on a network traversing
   NAT.  Discussions with many of the major NAT vendors have made it
   clear that they would prefer to deploy NATs that were deterministic
   and caused the least harm to applications while still meeting the
   requirements that caused their customers to deploy NATs in the first
   place.  The problem NAT vendors face is that they are not sure how
   best to do that or how to document how their NATs behave. 

http://www.cs.columbia.edu/sip/drafts/Ther0005_SIP.pdf

Use Cases

1. sipX on an internal network and behind NAT/firewall allows external phones to register
2. Two sipX servers on different networks and both behind NAT/firewall communicate and form one large system
3. sipX allows to register with external hosted voice provider

A more detailed description is being worked on and will be added shortly. Vovida's STUN server is planned to become part of the sipX NAT traversal solution and help would be appreciated to test and document.