SIP NAT, STUN & TURN

Solution to overcome this NAT issue is STUN

• STUN (Simple Traversal of UDP through NATs (Network Address Translation)) is a protocol for assisting devices behind a NAT firewall or router with their packet routing. RFC 5389 redefines the term STUN as 'Session Traversal Utilities for NAT'.
  
• STUN enables a device to find out its public IP address and the type of NAT service its sitting behind.
• STUN operates on TCP and UDP port 3478.
  
• STUN is not widely supported by VOIP devices yet.
• STUN may use DNS SRV records to find STUN servers attached to a domain. The service name is _stun._udp or _stun._tcp

STUN (Simple Traversal of UDP through NAT's)
allows your IP phone to discover NAT implementations (and the type of NAT it provides), in between the ip phone and the STUN server. for this reason most STUN servers are located on the Internet. Your IP phone, prior to making a SIP request, uses the STUN server to find out what NAT binding is in place, and rewrites its SIP packet accordingly. It can also be used to refresh NAT bindings (keep-alive as mentioned earlier). STUN operates great for all NAT implementations apart for symmetric NAT (explained in more detail below..).

TURN (Traversal using Relay NAT)


TURN operates in a ver similar way to STUN but also can handle RTP as well as SIP, meaning the media and signalling are proxied.
NAT


Network Address Translators modify the IP address and port information for packets traversing from one network to another. In its most typical incarnation, this is to used to manage private network ranges, and allow them to interract with publicly routed networks.

There are 4 types of NAT:

- Full
cone: The most simple (and least common in modern products) implementation. Operates in a similar way to Port address translation in that packets are accepted and forwarded according to NAT binding rules regardless of source.

- Restricted
cone: as above, with the NAT device maintaining a list of allowed originating devices

- Port restricted cone: applies port restrictions to the above

Symmetric: The most common in modern day solutions. A NAT 'binding' is created by the NAT device in response to a request made from internal_source_ip:port to public_destination_ip:port. This binding is kept alive so you can recieve responses from public_destination_ip:port (but it _has_ to come from this address/port combo). A new binding is created for each unique internal_source_ip:port combo that sends packets somewhere on a network that is external to your NAT device which controls your private LAN.

Network Address Translation (NAT) and SIP


There are several 'points of impact' where SIP finds NAT problematic, and it is not merely limited to NAT. RTP also has problems with NAT. Because SIP packets go out from a NATed client with their private (and un-routable) IP addresses coded into the message headers and SDP bodies, they are not processed by a NAT device, that operates only on the IP packets as they pass by. This then means that when the packets get to their destination, they are processed and responded to using completley useless source address information.

The 3 major problems of NAT in SIP


The VIA header problem: Responses to requests cannot he be routed back ot the originating party, as the supplied addressing information is not globally routable.

The CONTACT header problem: This refers to the fact that future requests would be routed incorrectly, again due to non-routable addresses being supplied.

The RTP problem: The final problem in the NAT/SIP category is to do with RTP (by that i mean the actual voice part of the session). The SDP messages which are used to negotiate the session format (codecs, ports, IP's etc), which are often enclosed within the SIP message body, and thus not processed by a SIP proxy according to IETF standards, will contain non-routable contact information as well (i.e. your internal address e.g. 192.168.x.x). This is a tough problem to solve.

There are several solutions to choose from to allow SIP to traverse NAT effectively. None of them is ideal, and much of it is external to SIP. The following sections refers to the
three main problems caused by SIP (listed above), and discusses the techniques applied within the protocol, and common third party solutions, to the problems.

Solutions to those 3 major problems


The Via header answer

This is solved within SIP. When a message arrives at a SIP server or UA, a comparison is made between the address the packet came from, and the one that is listed in the via header. If there is a difference, then the correct IP address (the one from which the packet originated from) is written as a parameter 'recieved=', and is added to the via header.

The contact header answer

This is a similar problem to the Via header issue, and is solved in the same way, updating the contact header instead. The contact header is referred to for communications that occur some time after an original request (such as BYE's or re-INVITE's), and this can cause additional problems, for the following reason:

NAT bindings are kept active on the NAT device for only a finite amount of time if SIP is being transported over UDP.

Solutions to this include using TCP for SIP instead of UDP (which is a connection-oriented protocol and so bindings and associated timeouts arent a problem), employing some kind of keep_alive program to maintain NAT bindings, or using STUN/TURN servers, or even a B2BUA.

The RTP answer


For instances where only one UA is behind a NAT device, symmetric NAT can be used. This effectively synchronizes the two RTP streams; the recipient of the successful RTP stream
(i.e. the globally routable UA in the session) transmits its RTP stream using the source IP of that RTP flow, ignoring the one that SDP has told it to use.

For instances where both users are behind NAT, you can employ a RTP proxy/media server/B2BUA of some kind to relay voice, breaking the call into two separate legs or you can use the TURN protocol (which essentially does the same thing).