NAT traversal with session border controllers: Difference between revisions

Revision as of 09:18, 10 April 2014

Revision as of 09:21, 10 April 2014

Line 6:

{{jargon|date=November 2013}}

[[Network address translation|Networknetwork Addressaddress Translatorstranslators]] (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]].

In case a user agent is located behind a NAT then it will use a private IP address as its contact address in the Contactcontact and Viavia headers as well as the [[Session Description Protocol|SDP]] 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 [[STUN]], [[TURN]] and ICE.<ref>Rosenberg, J. (April 2010). Interactive Connectivityconnectivity Establishmentestablishment (ICE): Aa Protocolprotocol for Networknetwork Addressaddress Translatortranslator (NAT) Traversaltraversal for Offeroffer/Answeranswer Protocolsprotocols. IETF. RFC 5245</ref> Which solution to use depends on the behavior of the NAT and the call scenario. When using an [[Session Border Controller|SBC]] to solve the NAT traversal issues the most common approach for SBC is to act as the public interface of the user agents.<ref>Hautakorpi, J.; Camarillo, G.; Penfield, R.; Hawrylyshen, A.; Bhatia, M. (April 2010). Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments. IETF. RFC 5853</ref> This is achieved by replacing the user agent’s contact information with those of the SBC.

== SBC Handlinghandling of Useruser Registrationregistration and NAT Traversaltraversal ==

[[File:SBC NAT Call Handling.jpg|thumb|NAT traversal handling with SBC during call establishment]]

In order for a user agent to be reachable through the public interfaces of an SBC, the SBC will manipulate the registration information of the user agent. The user includes its private IP address as its contact information in the [[Session Initiation Protocol|REGISTER]] requests. Calls to this address will fail, since it is not publicly routable. The SBC replaces the information in the Contactcontact header with its own IP address. This is the information that is then registered at the registrar. Calls destined to the user will then be directed to the SBC.

In order for the SBC to know which user agent is actually being contacted the SBC can keep a local copy of the user agent’s registration. The local copy includes the private IP address and the user’s [[URI|SIP URI]] as well as the public IP address included in the IP header that was assigned to the SIP message by the NAT.

Alternatively the SBC can store this information in the forwarded SIP messages. This is displayed in the figure here. The user’s contact information is combined in a special format and added as an additional parameter to the Contactcontact header. The contact information include the user’s private IP address and SIP URI as well as the public IP address in the IP header of the SIP message. When the registrar receives a request for the user, the registrar will return the complete contact information to the proxy, which will include this information in the SIP message. The SBC can then retrieve this information from the SIP request and use it to properly route the request to the user.

Adding the user agent’s contact information to the registered contact information has many advantages. As the SBC does not have to keep local registration information this solution is simple to implement and does not require memory for keeping the information. Further, requests destined to the user agent do not necessarily have to traverse the SBC that has processed the user agent’s registration messages. Any SBC that can reach the user agent can correctly route messages destined to the user agent based on the information included in the SIP request. This advantage applies, however, only in some cases. In case the NAT used in front of the user agent accepts traffic only from the IP addresses which the user agent has contacted previously then only the SBC that has processed the user agent’s REGISTER requests will be able to contact the user agent.

Line 31:

However, keeping a local copy of the registration information has its advantages as well. When receiving a message from a user agent a network address translator binds the private IP address of the user agent to a public IP address. This binding will remain active for a period of time –binding period. In case the user agent does not send or receive any messages for a period of time longer than the binding period then the NAT will delete the binding and the user agent will no longer be reachable from the outside. To keep the binding active, the user agent will have to regularly refresh it. This is achieved by sending REGISTER requests at time intervals shorter than the binding period. As REGISTER messages have to be usually authenticated, having to deal with REGISTER messages sent at a high frequency would impose a high performance hit on the operator’s infrastructure. SBCs can help to offload this load. When a user agent sends the first REGISTER request, the SBC forwards the REGISTER request to the operator’s registration servers. Once the registration was successfully authenticated and accepted by the operator, the SBC will keep a local copy of the registration information. Instead of forwarding each incoming REGIETER request to the operator’s registration servers, the SBC will only send REGISTER requests to the registration servers at rather large time intervals (in the range of hours). Registration requests arriving from the user agent that do not change the content registration information will be replied to by the SBC itself. The SBC will also inform the registration server once the local registration expires or changes.

== SBC Handlinghandling of Callcall Establishmentestablishment and NAT Traversaltraversal ==

[[File:SBC NAT Registration Handling.jpg|thumb|NAT traversal with SBC during user registration]]

Similar to the registration case, the SBC will also include itself in the path of [[Session Initiation Protocol|INVITE]] and other request messages. When receiving an INVITE from a user agent behind a NAT, the SBC will include a Viavia header with its own address, replace the information in the contact header with its own address and also replace the address information in the [[Session Description Protocol|SDP]] body with its own address. Thereby, all SIP messages and media packets will traverse the SBC.

== SBC Handlinghandling of Mediamedia Packetspackets and NAT Traversaltraversal ==

After the establishment of a call using SIP, media packets, namely voice, video or data are exchanged -usually using the [[Real-time Transport Protocol]] (RTP)

Line 47:

The other noticeable disadvantage is "triangular routing": an SBC must relay all VoIP traffic for a call, to make the paths caller-SBC and SBC-callee symmetric. That is in fact quite an overhead for a VoIP operator. With the most common codec, [[G.711]], a relayed call consumes four 87.2 kbit/s streams: two outbound, two inbound.

Some other disturbing limitations may occur too. For example, if a SIP device uses [[Voicevoice Activityactivity Detectiondetection]] (VAD) and fails to send any voice packets initially, the SBC will not learn its address and will not forward incoming media to it as well.

== References ==