User's Manual

36
CHAPTER 6. TRAVERSING NAT
6.1 Introduction
Network Address Translation (NAT) is a methodology of remapping internal IP address space to
external one by modifying source/destination network address and port field in IP packets when they are
transmitted through router or firewall. Not all of network devices could be assigned to a public IP address
when it accesses internet due to the shortage of amount of IPv4 address. The NAT helps a lot of these
network devices to share public IP address to visit Internet.
But it is very hard to send information to the device under NAT. And it is crucial to VoIP device
because server needs to know how to send incoming call request to the phone in local private network.
NAT traversal has been proposed to solve this problem. There are many technologies that could be used
to do NAT Transversal, such as STUN (RFC5389), ICE(RFC5245), TURN(RFC5766), symmetric
Response (RFC3581, Rport), etc. In this guide, we only discuss two NAT Traversal methods which X
series phone have implemented.
6.2 STUN
Session Traversal Utilities for NAT (STUN) is a network protocol to allow network device to discover
its public IP address through the assistant of 3-party sever on public network. It could also discover the
NAT type and binding port of NAT for local network device.
After applying the appropriate configurations for STUN, or loading the STUN configuration, our X
series phone would access STUN server first to detect the public IP address, NAT binding port and type of
NAT. There are four types of NATs generally, which STUN could not handle the traversal under symmetric
NAT. After the STUN server responds successfully, phone would send packets to STUN server through
SIP local port (default 5060), and wait the response to modify SIP URI. Then a request from local network
to public SIP server would contain URI information like packets to which a public IP address sent. Sever
feeds back response to the public IP address and port would come back to local device through NAT. So,
server could find local device under NAT easily. When phone call is made, it would use STUN to discover
binding RTP port on NAT again, and fill out the information on SDP session. And then a voice media
connection would be built between local device and public device.
Note:
1. STUN could not handle the case under symmetric NAT.