Network address translation (NAT) is the process whereby network addresses residing behind a device are mapped to a network address on the other side of the device. NAT devices are mainly used to alleviate IPv4 address exhaustion by allowing the use of private IP addresses on local networks with a single public IP address facing the cloud.
Network address translator traversal is a networking method of establishing and maintaining connections across gateways that implement network address translation.
NAT traversal is a well-known and understood problem in distributed computing. Presently, the majority of the work to resolve the issues related to NAT traversal has been done within in the telecom world to enable peer-to-peer Voice-over-IP communications. There are several standards that have been developed by the Internet Engineering Task Force (IETF) and adopted by the industry to reliably traverse NATs:
- RFC 5389 “Session Traversal Utilities for NAT (STUN)” is a standardized set of methods, for NAT traversal of network address translator (NAT) gateways in applications of interactive communications”
- RFC 5766 “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)” is a protocol that assists in traversal of network address translators (NAT) or firewalls for multimedia applications”
- RFC 5245 “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols” is a technique used for NAT traversal for UDP-based media streams established by the offer/answer model
ICE is used in combination with STUN and TURN protocols as well as a signaling protocol, such as Session Initiation Protocol (SIP, described in RFC 3261), to negotiate client-to-client media streams in NAT-enabled networks.
Our NAT Traversal Solution
Akimbo Technologies architecture uses a light-weight SIP stack and an implementation of the ICE standard that has been customized to support our Fault-Tolerant Distributed Computing (FTDC) technology. These protocols provide the necessary building blocks for establishing the client-to-client media connections amongst game clients. The Akimbo Technologies’ “Game Management Server” performs the role of SIP proxy server, providing game client login services via SIP registration and game session management services such as SIP call establishment and call control messaging.
In addition, the game management server provides the STUN/TURN server functionality required for NAT traversal. The ICE standard describes using the SIP offer/answer mechanism to negotiate RTP media streams in conjunction with RFC 3264 “Offer-Answer Model”. Our ICE client negotiates our proprietary FTDC media streams that transport game session data between FTDC game clients.
During the process of joining a game session, ICE clients gather a list of candidate IP addresses to use for media stream connections with other peer game clients. When negotiating the media stream with another game client, the SIP client creates SDP offer/answer payloads that include the list of ICE candidate addresses. Once each ICE client has received the peer endpoint’s candidate address list, it starts testing the permutations of candidate address pairs for connectivity. After the testing concludes, both endpoints will have determined the same “best-match” candidate pair, resulting in an established client-to-client media connection between the peers.
One of the main advantages of this approach is that the SIP call control signaling does not look any different than VoIP calls.