NAT traversal with session border controllers: Difference between revisions

Revision as of 09:21, 10 April 2014

Revision as of 21:03, 24 June 2017

Line 7:

[[Network address translation|network address translators]] (NAT) are used to overcome the lack of [[IPv4]] address availability by hiding an enterprise or even an operator’s network behind one or few [[IP address]]es. The devices behind the [[Network address translation|NAT]] use [[private IP address]]es that are not routable in the public Internet.

The [[Session Initiation Protocol]] (SIP) has established itself as the de facto standard for [[voice over IP]] (VoIP) communication.<ref>Sinnreich, Henry; Johnston, Alan B. (2001), Internet Communication Using SIP, Wiley, p. 180, {{ISBN |0-471-77657-2}}</ref> In order to establish a call, a caller sends a [[Session Initiation Protocol|SIP]] 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 [[IETF]] leadership that IP address space would be exhausted more rapidly and would necessitate global upgrade to [[IPv6]] 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: [[Session Border Controller]]s (SBC)<ref>{{cite web|title=Understanding Session Border Controllers|url=http://www.frafos.com/wp-content/uploads/2012/10/FRAFOS_Underdstanding_SBC.pdf}}</ref> were born, and began to fix what the standards failed to do: [[NAT traversal]].