NAT/ALG Method
Standard NAT translates addresses by modifying the header information in UDP or TCP packets. However, for VoIP applications, address information also needs to be carried within the TCP/UDP payload. The ALG (Application Layer Gateway) method works such that the VoIP endpoint in the private network fills its private address into the payload; this address information is then modified to the NAT’s public external address when traversing the NAT.
This approach requires the ALG function to reside on the NAT/Firewall device, demanding that these devices themselves possess the intelligence for application recognition. It requires support for identifying IP voice and video protocols (H.323, SIP, MGCP/H.248) and controlling the NAT/Firewall. Furthermore, every time a new application is added, the NAT/Firewall must be upgraded.
Some compromises on security are also required, because the ALG cannot recognize the content of encrypted packets, so communication must be in plain text. This poses a significant security risk when packets travel over the public internet. The NAT/ALG method is the simplest way to support VoIP NAT traversal, but given the reality that a large number of deployed NAT/FW devices do not support this feature, it is very difficult to adopt this method in practice.
MIDCOM Method
Unlike NAT/ALG, the basic framework of MIDCOM uses a trusted third party (MIDCOM Agent) to control the Middlebox (NAT/FW). The recognition of VoIP protocols is not performed by the Middlebox itself but by an external MIDCOM Agent. Therefore, the protocol used by VoIP is transparent to the Middlebox.
Since the function of identifying application protocols is moved from the Middlebox to an external MIDCOM Agent, this architecture allows for support of more new services simply by upgrading the MIDCOM Agent, without needing to change the basic characteristics of the Middlebox. This is a significant advantage over the NAT/ALG method.
In practical VoIP applications, the Middlebox function can reside on the NAT/Firewall. Through a softswitch device (i.e., the MIDCOM Agent) that identifies IP voice and video protocols (H.323, SIP, MGCP/H.248) and controls the NAT/Firewall, VoIP applications can traverse the NAT/Firewall. In terms of security, the MIDCOM method supports encryption of control messages and media streams, thus offering relatively high security.
If protocol identification for SIP/H.323/MGCP/H.248 is implemented on the softswitch device, only the MIDCOM protocol needs to be added to both the softswitch and NAT/FW devices. Moreover, future new application service identifications will be supported as the softswitch evolves. This solution is a promising one, but it requires existing NAT/FW devices to be upgraded to support the MIDCOM protocol. From this perspective, it is also quite difficult for the large base of already deployed NAT/FW devices, presenting the same problem as the NAT/ALG method.
STUN Method
Another approach to solving the NAT traversal problem is that the VoIP endpoint in the private network obtains the public-facing address on the egress NAT in advance through some mechanism, and then directly fills this public address into the payload’s address information instead of the endpoint’s private IP address. This way, the payload content does not need to be modified when passing through the NAT; only the IP address in the packet header needs to be translated following the standard NAT process. The IP address information in the payload stays consistent with the address information in the packet header. The STUN protocol is based on this idea to solve the application-layer address translation problem.
STUN stands for Simple Traversal of UDP Through Network Address Translators. An application (the STUN CLIENT) sends a STUN request message via UDP to a STUN SERVER located outside the NAT. Upon receiving the request, the STUN SERVER generates a response message that carries the source port of the request message鈥攚hich is the corresponding external port assigned to the STUN CLIENT on the NAT.
The response message is then sent back to the STUN CLIENT through the NAT. The STUN CLIENT learns its external address on the NAT from the content of the response message body and fills this into the UDP payload of subsequent call protocols, informing the remote end that its local RTP receiving address and port number are the NAT’s external address and port number. Since a NAT mapping entry for the media stream has been pre-established through the STUN protocol, the media stream can smoothly traverse the NAT.
The biggest advantage of the STUN protocol is that it requires no changes to existing NAT/FW devices. In practice, a huge number of NAT/FW devices are already deployed, and many do not support VoIP applications. Solving this problem using MIDCOM or NAT/ALG would require replacing existing NAT/FW devices, which is not easy.
Requiring no changes to the NAT/FW is the greatest advantage of the STUN method. The STUN method can also work in network environments with multiple levels of NAT, whereas the MIDCOM method cannot effectively control multi-level NAT scenarios.
The limitation of STUN is that it requires the VoIP endpoint to support STUN CLIENT functionality. Additionally, STUN is not suitable for supporting the traversal of TCP connections, and therefore does not support H.323. Furthermore, the STUN method does not support traversal through firewalls, nor does it support traversal of Symmetric NAT types (which are common in enterprise networks with high security requirements).
TURN Method
The approach of the TURN method to solving the NAT problem is similar to that of STUN. Through some mechanism, the VoIP endpoint in the private network obtains a service address on the public network in advance (the address obtained via STUN is the external address on the egress NAT, while the address obtained via TURN is a public address on the TURN Server), and then fills this public address directly into the address information required in the packet payload.
TURN stands for Traversal Using Relay NAT. The TURN application model allocates an address and port on the TURN Server as the public-facing receiving address and port for the VoIP endpoint in the private network. This means all packets sent by the private network endpoint must be relayed and forwarded through