NAT traversal with session border controllers

<a href="/facts/Network_address_translation/nFweFNfN">Network address translators</a> (NAT) are used to overcome the lack of <a href="/facts/IPv4/bnQ5MEqm">IPv4</a> address availability by hiding an enterprise or even an operator's network behind one or few <a href="/facts/IP_address/z9V22Sw9">IP addresses</a>. The devices behind the <a href="/facts/Network_address_translation/nFweFNfN">NAT</a> use <a href="/facts/Private_IP_address/CqVdg83c">private IP addresses</a> that are not routable in the public Internet.
The <a href="/facts/Session_Initiation_Protocol/cbjUoNqP">Session Initiation Protocol</a> (SIP) has established itself as the de facto standard for <a href="/facts/Voice_over_IP/5QGBbXYg">voice over IP</a> (VoIP) communication. In order to establish a call, a caller sends a <a href="/facts/Session_Initiation_Protocol/cbjUoNqP">SIP</a> message, which contains its own IP address. The callee is supposed to reply back with a SIP message destined to the IP addresses included in the received SIP message. This will obviously not work if the caller is behind a NAT and is using a private IP address.
Probably the single biggest mistake in SIP design was ignoring the existence of NATs. This error came from a belief in <a href="/facts/IETF/tIcCsFhX">IETF</a> leadership that IP address space would be exhausted more rapidly and would necessitate global upgrade to <a href="/facts/IPv6/d4dg7kIL">IPv6</a> and eliminate the need for NATs. The SIP standard has assumed that NATs do not exist, an assumption, which turned out to be a failure. SIP simply didn't work for the majority of Internet users who are behind NATs. At the same time it became apparent that the standardization life-cycle is slower than how the market ticks: <a href="/facts/Session_Border_Controller/Nepbz3uk">Session Border Controllers</a> (SBC) were born, and began to fix what the standards failed to do: <a href="/facts/NAT_traversal/HVds5bqC">NAT traversal</a>.
In case a user agent is located behind a NAT then it will use a private IP address as its contact address in the contact and via headers as well as the <a href="/facts/Session_Description_Protocol/WMnnA5jb">SDP</a> part. This information would then be useless for anyone trying to contact this user agent from the public Internet.
There are different NAT traversal solutions such as <a href="/facts/STUN/adARyNV0">STUN</a>, <a href="/facts/TURN/mm3U33xV">TURN</a> and ICE. Which solution to use depends on the behavior of the NAT and the call scenario. When using an <a href="/facts/Session_Border_Controller/Nepbz3uk">SBC</a> to solve the NAT traversal issues the most common approach for SBC is to act as the public interface of the user agents. This is achieved by replacing the user agent's contact information with those of the SBC.

NAT traversal with session border controllers open-in-new

NAT traversal with session border controllers