In recent years, Voice-over-IP (VoIP) has become popular and many VoIP products have been developed. VoIP phones enable people call each other through the Internet in the same way as they dial a PSTN phone call, and reduce the cost for telephony. This is the main advantage of VoIP. However, firewall and Network Address Translator (NAT) [1]
traversal problem makes VoIP applications difficult to use in private intranets. Numerous researches have been conducted to overcome the problem. In this thesis, we present a new mechanism that solves NAT traversal without modifying NAT devices, and considers all cases of call setup and their optimal solutions. We integrate Session Initiation Protocol (SIP) [2] registration with relay server assignment, SIP-based NAT type detection, hole punching, and RTP port allocation and so on. Hole punching is the procedure that an internal host of a NAT sends a packet to external host, and produces a mapping port on the NAT.
1-1. Related work
Figure 1-1: SIP architecture
SIP is a signaling protocol handling setup, modification, and tear-down of multimedia sessions. SIP was defined in Request for Comments (RFC) 2543 by a working group of Internet Engineering Task Force (IETF), and a new SIP RFC has been produced, RFC number 3261. Figure 1-1 describes the SIP architecture with NAT devices. SIP is a client-server protocol. A registrar accepts registration requests from SIP UAs and maintains their information. A SIP UA is a client that can be used to set up multimedia communications over the Internet, and can be installed on a PC, a PDA, or a SIP phone.
1-2. NAT traversal problem and possible solutions
NAT traversal problem
NAT was originally developed as a short-term solution to combat IPv4 address exhaustion. It allows globally registered IP addresses to be reused or shared by several hosts.
The classic NAT defined by RFC 1631 [3] maps IP addresses from one realm to another.
Although it can be used to translate between any two address realms, NAT is most often used to map IP address from the non-routable private address defined by RFC 1918 [4].
NAT, while providing many benefits, also comes with many drawbacks. The most troublesome of those is the fact that they break many existing IP applications and make it difficult to deploy new ones.
In RFC 3489 [5], NAT were grouped into four types: full-cone NAT, restricted cone NAT, port-restricted cone NAT, and symmetric NAT.
(1) Full cone: a full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address.
(2) Restricted cone: a restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X.
(3) Port Restricted cone: a port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.
(4) Symmetric: a symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.
Possible solutions
In this section, we don’t consider solutions, such as ALG [6], UPnP, Middlebox [7], that solve the traversal problem by modifying the NAT itself. The number of existing NAT is too huge.
SIP extension for NAT traversal: it allows for SIP responses to go back to the source
port of the request and allows a registrar to get the source IP/port instead of the “Contact” in a REGISTER. We consider that this extension just helps the development of traversal solution, rather than a completed solution.
Simple Traversal of UDP through NAT (STUN): the protocol allows entities behind
a NAT to discover the presence of a NAT and its type, and then to learn the addresses bindings allocated by the NAT. STUN requires no changes to NAT devices, and works with an arbitrary number of NATs in tandem between the application entity and the public
Internet. However, STUN can’t resolve the case of symmetric cone NAT.
Traversal Using Relay NAT (TURN) [8]: TURN allows a client to relay packets
through a server that resides on the public Internet. Although TURN will almost always provide connectivity to a client, it comes at high cost to the provider of TURN server. It is therefore desirable to use TURN as a last resort only, preferring other mechanisms (such as STUN or direct connectivity) when possible.
Interactive Connectivity Establishment (ICE) [9]: ICE is not a new protocol. It
makes use of both STUN and TURN protocols, but uses them in a specific methodology which avoids many of the pitfalls of using any one alone. The key idea behind ICE is that network conditions and connectivity assumptions can, and will change. Therefore ICE clients have no need to know whether they are behind a NAT, its type, or network topology.
ICE always will find a means for communicating if one physically exists.
An ICE client has many addresses where it can receive media, such as local IP address, addresses learned from a STUN server, or a TURN server. It has to gather as many addresses as possible and includes them in its INVITE message, and decides the priority of addresses based on lowest cost and maximum Qos before making a call. When the called party receives the INVITE message, it will do the same allocation steps as caller, and verify the connectivity of each address in the receiving message and choose the appropriate address to send media sessions based on the priority.
The advantage of ICE is that clients have no need to know the NAT type and network topology. It solves all kinds of NAT traversal problem with the cheapest path for service provider. However, we find some unnecessary overhead in ICE. First, we think that there are no needs to do so many tasks when establishing calls. If we assure the NAT type and route address ahead of time, for example: during registration, we don’t need allocate more than one addresses and verify their connectivity when making a call. Second, if we choose to implement ICE protocols, we must also need to maintain STUN servers and TURN
servers in the public network for clients. Third, ICE clients needs to serve as a STUN server when the called party wants to verify the connectivity of addresses.
1-3. The solution of the thesis
The following table presents the comparison of call setup overhead between ICE and the proposed solution in the thesis:
Table 1-1: call setup overhead: ICE vs. proposed solution
In the thesis, a SIP UA will detect the presence of NAT and its type, and assures route address during registration. Thus the UA does not need to check the connectivity of route address. In other words, we can eliminate the procedures of address prioritization and verification when making calls and reduce overhead further.
1-4. Overview of the thesis
The rest of this thesis is organized as follows. Chapter 2 describes the overall NAT traversal mechanism. Chapter 3 describes how to design and implement such a system presented in the previous chapter. At last, Chapter 4 gives conclusions and discusses future work for the thesis.