NAT traversal with session border controllers: Difference between revisions

Revision as of 13:13, 23 October 2013

Revision as of 11:49, 25 October 2013

Line 1:

{{AFC submission|t||ts=2013041915091720131023131315|u=Bbutscher|ns=5}} <!--- Important, do not remove this line before article has been created. --->

[[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.

Line 8:

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 [[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 Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. 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 Handling of User Registration and NAT Traversal ==

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

Line 24 ⟶ 25:

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 Handling of Call Establishment and NAT Traversal ==

[[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 Via 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 Handling of Media Packets and NAT Traversal ==

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)

While NAT traversal of SIP messages may appear complicated after all, the yet more complex task is enabling media to traverse NATs. The initial problem statement is the same. If SIP devices behind NATs advertise their IP addresses, their peers on the other side of NATs cannot route traffic to them.

Line 39 ⟶ 44:

Some other disturbing limitations may occur too. For example, if a SIP device uses [[Voice Activity Detection]] (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 ==

{{reflist}}

<!--- After listing your sources please cite them using inline citations and place them after the information they cite. Please see http://en.wikipedia.org/wiki/Wikipedia:REFB for instructions on how to add citations. --->

*

*

*

*

<!-- Just press the "Save page" button below without changing anything! Doing so will submit your article submission for review. Once you have saved this page you will find a new yellow 'Review waiting' box at the bottom of your submission page. If you have submitted your page previously, the old pink 'Submission declined' template or the old grey 'Draft' template will still appear at the top of your submission page, but you should ignore them. Again, please don't change anything in this text box. Just press the "Save page" button below. -->

{{AFC submission|||ts=20131023131315|u=Bbutscher|ns=5}}