Nat

http://www.voiptraversal.com/solving_nat_traversal.htm

To solve the NAT traversal problem, the industry has attempted a few solutions:

Application Level Gateway (ALG): An ALG acts as a protocol-aware firewall, monitoring traffic and permitting traffic flows for specific applications. This solution, however, does not ensure security or authenticity, and is difficult to deploy.

Session Border Controller (SBC): An SBC addresses some of the problems that ALGs fail to resolve. However, this solution is not scalable for large numbers of concurrent calls. Moreover, it introduces additional delay and packet loss with the ultimate consequence of inferior end-user experience. Since SBCs use proprietary methods for NAT traversal, they do not work with SBCs from other vendors and/or third party solutions.

IETF STUN, TURN and ICE: The IETF (Internet Engineering Task Force) has devised a suite of protocols, namely STUN (Session Traversal Using NAT) [1], TURN (Traversal Using Relay NAT) [2], and ICE (Interactive Connectivity Establishment) [3], to address the limitations of the currently available NAT traversal solutions.
- STUN lets the applications discover the public IP address and port mappings that the applications can use to communicate with its peer.
- TURN, on the other hand, allocates a public IP/port on a globally reachable server and uses it to relay media between communicating parties. 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.
- ICE is a framework that defines how to use the STUN and TURN protocols to solve the NAT traversal problem, by choosing the best possible interconnection method between two users. Since ICE incorporates STUN and TURN methods, sometimes ICE is also used to refer to the complete STUN, TURN, and ICE solution.

types of NAT

http://en.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT
https://docs.google.com/a/google.com/viewer?url=http://www.crfreenet.org/~martin/referaty/stun/naty.pdf

There are 4 types of NAT:

the best explaining: http://think-like-a-computer.com/2011/09/19/symmetric-nat/

A symmetric NAT applies restrictions exactly the same way as a port restricted cone NAT but handles the NAT translation differently. All types of NAT discussed so far don’t change the source port when NATing connections. For example when a client accesses the Internet using IP 192.168.0.1 and source port 56723 NAT changes the source IP to say 56.35.67.35 but keeps the port number the same; this is known as port preservation. A symmetric NAT NATs ports to new randomly generated ones. This even applies to connections from the same client to different destinations.

STUN: STUN is quite simple in how it works. You connect to a server running the STUN protocol (xbox live servers) and it reads the source IP address and source port from the incoming packets. it uses the same ONE mapping when sending and receiving packets to several devices on the Internet therefore it uses the same public IP address and port. In the case of a symmetric NAT however every single connection has a different mapping with a different (randomly generated) port; the connection to the STUN server will have it’s own unique mapping as will every other console…which means different ports for each mapping. In this case the port that the STUN detected is now useless as this mapping is exclusive to the STUN server. Whatever port is used in the mapping to other devices is unknown and there is no way for STUN to detect it.

for Full-cone, restricted cone, or port restricted cone, All requests from the a particular internal IP address and port are mapped to the same external IP address and port.

- Full cone: any external host can send a packet to the internal host, by sending a packet to the mapped external address.

- Restricted cone:The same as full-cone NAT but an external host X can send a packet to the internal host only if the internal host has previously sent a packet to X.

- Port restricted cone: Like the restricted cone NAT, but the external host can only send a packet to the internal host on a port which the internal host has previously sent a packet to.

full cone, port restricted and restricted cone always mapped inner_ip:port to one public_ip:port, doesn't matter how many external contact hosts. for restricted cone, once internal host sends traffic to external_host:__, the external_host will be added into white-list of incoming traffic. for port restricted cone, once internal host sends traffic to external_host:port, the external_host:port will be added into white-list of incoming traffic.

- 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 receive 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 - public_destination_ip:port combo.

what is symmetric RTP

Symmetrical RTP is a trick to extend the number of cases when communication can be established. A SIP user agent that supports symmetrical RTP waits for the first RTP packet coming in and then sends its media stream
back to the IP address from which it received that packet. Symmetrical RTP works always if the user agent that does symmetrical RTP is on a globally routable address. However, this algorithm can easily be cheated (port spraying) and therefore implies a certain security risk

[[ file FAQ-03-10-20-cs.pdf | FAQ-03-10-20-cs]]

excellent ICE illustration

http://www.voiptraversal.com/ice_methodology.htm

great tutorial from Nokia

nokia tutorial
Jonathan Rosenberg

import notes for ICE

- STUN requests need to be multiplexed with RTP; SIP end point needs to fully implement STUB protocol; RTP send and receive of a particular media (such as audio)should use the same port.

- in STUN response, the reason to XOR IP:port is because some NAT pretends to be smart and automatically change IP address in your packet. this XOR will defeat that.

It turns out that some NAT devices try to be clever by inspecting the payloads and changing all references to the server-reflexive address into the private address. To address that issue, the new version of STUN
(known as STUN 2) obfuscates the address by XORing it with a known value.

ICE

- ICE does not work if both sides behind symmetric NATs. only TURN can work at this case.
- in fact, the following trick work almost as ICE besides it does not allow early media.

To figure out the RTP IP and port from the first packet that arrives on the local RTP IP and port of the server, and to use it instead of using the RTP IP and address declared in SDP. This trick solves the NAT traversal problem, no matter how many NATs the client is traversing. However, the main disadvantage is that, in some cases, the client will not receive early media (since at that point, it sends out no voice packets) and it will not hear the ringing.
http://freecode.com/articles/nat-traversal-for-the-sip-protocol

- peer reflexive candidates. Typically happends when there is a symmetric NAT between users.

- disadvantages of TURN:

● ICMP not relayed. - No path MTU discovery.
● TTL not properly decremented. – Possibility of loops.
● DiffServ (DS) field not relayed.
● As of now only IPv4 and UDP.

+++two approaches for NAT

- solving the problem in the client: STUn, TURN, ICE. resolve the problem in the server: MediaProxy.
refer MediaProxy

- the two main schools for SIP NAT traversal (far end and near end). In a nutshell, far end NAT traversal is implemented by the server. This is the FreeSWITCH default. The SDPs are rewritten to the address of the FreeSWITCH server and passed to the remote endpoint. This causes the media to be relayed at the server between the endpoints. This has the advantage of being universally compatible - regardless of how dumb the endpoint(s) is/are. Disadvantages are many - increased sever load, bandwidth, latency, etc. However, with many endpoints this is the only choice.

Near end NAT traversal relies on advances technologies such as STUN, TURN, and ICE to be supported by the client (and the servers to enable them configured and available). TURN actually blurs the lines between these two strategies, as do various hybrid approaches using local proxies, etc but that's for another day.

Bypass media is incompatible with NAT unless you're using STUN/TURN/ICE in your clients

https://wiki.freeswitch.org/wiki/NAT_Traversal

NAT issue for registration:

- registrar automatically replace contact address with the source_ip:port it observes the registration request from.
- registrar uses rport and client needs to have the capability to support this.

The clients begins with sending a REGISTER with a private IP in *both* Contact and Via, Via also containing rport parameter. The server will reject the request, adding received and rport parameters with the IP and port from the packet. therefore when the client receives the response, the top (and only one) Via contains the external IP and port. Now the client can resubmit the REGISTER with the external IP and port in the Contact (but private IP in Via), which should be accepted.
http://wiki.ekiga.org/index.php/Understanding_NAT/firewall_issues_with_SIP_clients_%28eg_ekiga%29

how to keep NAT binding work:

best practice of NAT

http://www.ag-projects.com/publications-corporate-176/151-best-practices-for-sip-nat-traversal

NAT Traversal Practices for Client-Server SIP(rfc 6314)
natfriendly_mar01.ppt

other tutorial

SIP NAT
VoIPTutorial from Columbia university
http://www.slideshare.net/oej/sip-2012-ice-nat-traversal-for-media
NAT tutorial from IETF

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License