Network Address Translation (NAT)/Network Address and Port Translation (NAPT) and NAT Traversal are central in any real-time voice and/or video (VoIP) communications. The possibility to communicate end-to-end across private and public networks is crucial in most voice and video use cases.
This blog post explains the role of NAT/NAPT and NAT Traversal and how it addresses the challenges associated with private and public IPv4 addresses. It is part of a mini-series of technical blog posts looking at the key capabilities needed for mission critical and real-time voice and video communications.
In a separate post we give an overview of a SIP server, how it works and why it is essential in a SIP and WebRTC-based communications infrastructure. Go here for the SIP Server blog post →
What is NAT?
NAT is used to translate private IPv4 addresses to one or a few public IPv4 addresses. Private IP addresses is a defined range of IPv4 networks, defined in RFC 1918, that are only to be used in local private networks. The private IPv4 address ranges cannot be routed on the public internet, but the NAT/NAPT allows devices that are connected to the local private network to communicate with a public IPv4 address. Whenever a device with a private IPv4 address needs to communicate with a device on the public internet, NAT/NAPT must be applied at the edge of the private network to map that private IPv4 address to a public globally routable IPv4 address.
In the scenario where multiple devices on a private network need to communicate with public IP addresses through one NAT device with one public IP address (which is the normal case) a combination of IP address and port is used. This combination is called NAPT and is the normal solution in residential use cases.
The NAT/NAPT approach breaks the end-to-end model of the internet but solves the problem with the shortage of public IPv4 addresses.
Below illustration shows a conceptual view of where in the network the NAT device and the NAT Traversal mechanism are located.
Conceptual view of where in the network the NAT device and the NAT Traversal mechanism are located.
NAT in SIP and WebRTC-based communication
Due to the nature of most SIP and WebRTC-based real-time voice and video communications there is an added complexity in getting end-to-end communications to flow. Many services rely on a strict client – server relationship where the client always initiates the communication to a server placed on the Internet. Simply put, as long as the server is reachable using a public IPv4 address it is not a problem if the client is not reachable since the NAT will translate the private IPv4 address and keep a mapping, a “pinhole”, open for that specific communication. All responses sent back from the server for that communication will be translated and forwarded to the client on the private address on the “inside”.
However, in SIP and WebRTC-based communication, the flows are usually separated in a signaling flow and one or more media flow(s). The signaling flow can in some cases be compared to the client – server type of traffic as described above and has less of a problem working with NAT.
The signaling flow contains information about the actual media flows (e.g., the destination of the flow, codecs used, the media type to negotiate and UDP/RTP ports) as well as where to send further signaling. The NAT will have no understanding of this information, not be able to translate it or open pinholes for it. Because of this there will in most cases not be any associated state or “pinhole” when the actual media stream is received. Alternatively, the media might be sent to the wrong destination.
Furthermore, the private IPv4 address indicated in the call signaling may very well not be reachable from the IP network of the receiver. It may even be sent to the wrong place since the private IPv4 addresses can be re-used in different local networks.
Below image shows the signaling and media flow of end-to-end communication in a scenario where both endpoints have public IPv4 addresses, hence NAT is not needed.
End-to-end connectivity with both endpoints reachable. No NAT traversal mechanism needed.
NAT introduces complexity
As soon as one of the devices are placed behind a NAT, the complexity grows. The media flow will have issues even if the signaling could be handled with relatively simple NAT traversal techniques. The issues could be:- Remote endpoints can’t send media packets to the private IPv4 address of the device that is behind the NAT and packets will be lost since there is no IP route available.
- The NAT device will not have any states / pinholes open that relates to the incoming media stream.
Broken end-to-end connectivity with one endpoint placed behind a NAT.
To solve this, hosted NAT traversal can be applied to make sure that media successfully can flow end-to end. This is done by invoking the media relay and hosted NAT traversal mechanisms of the SIP Server.
Below illustration shows the signaling and media flow of end-to-end communication in a scenario where one of the endpoints is on an internal network, hence has a private IPv4 address. A NAT device is therefore needed and consequently the need for a NAT traversal mechanism.
Successful end-to-end media flow with hosted NAT Traversal. The hosted NAT Traversal will even ensure end-to-end delivery of media flow in scenarios where both endpoints are placed behind different NAT devices.
What is NAT Traversal?
NAT traversal is a toolbox of different technical solutions to work-around the lack of end-to-end connectivity that is introduced with the NAT. It consists of different types of signaling modifications and media flow anchoring to make sure that devices situated on private IPv4 networks and behind NAT, can receive inbound media flows.
There are many different types of NAT devices, and they act in different ways. Consequently, different NAT traversal mechanisms are required and in some rare cases, traversal is not practically possible. In most cases however, a hosted NAT traversal approach will solve the NAT problem.
Usually, a NAT device will only allow incoming IPv4 packets from a source that is associated with an outbound connection. This means, that if a device on the private network behind the NAT is making an outbound connection to a server on the internet, the NAT device will establish a state for that connection making it possible for that server to send IPv4 packets back to the specific source. As long as the NAT device can keep that association, the NAT device will know where to forward the returning IPv4 packet.
However, if the state is lost, or if a packet is received from another server (other IP/port) on the internet, the NAT has no understanding of where to forward the IPv4 packet to and most likely will drop it. If that IPv4 packet was supposed to carry voice or video samples, the result is lack of voice or video, at least on the receiving end.
Why is NAT Traversal important?
For all real-time voice and video communications services to work properly end-to-end between private and public networks, NAT traversal is crucial. If NAT traversal is not handled correctly there will be no reliable end-to-end communications between endpoints with private and public IPv4 addresses.
How is NAT Traversal used in the iotcomms.io platform?
Hosted NAT traversal is a feature natively built into the iotcomms.io platform. SIP or WebRTC-based voice and video services or applications built with the iotcomms.io platform will have NAT traversal invoked whenever needed to deliver end-to-end communication.
The hosted NAT traversal feature will during session establishment determine the NAT traversal technique needed to establish end-to-end communication for a particular session. Depending on network topology and type of sessions established, various levels of hosted NAT traversal mechanisms will be needed. Media streams might need to be anchored completely in the iotcomms.io platform to achieve the end-to-end communication, while in other cases less intrusive actions are sufficient.
The iotcomms.io cloud native communications platform takes care of the challenges and pitfalls of handling the NAT traversal. Voice and video communications services built on iotcomms.io are successfully delivered end-to-end to the involved endpoints – on an internal network or at the internet – with the reliability and availability expected for mission critical real-time use cases.
Summary
NAT traversal is crucial for end-to-end communications to work between private and public IPv4 addresses. The nature of SIP and WebRTC-based traffic makes NAT traversal even more complex and requires key competence to handle successfully.
iotcomms.io offers hosted NAT traversal as part of its SIP server as a Service. Delivered as a managed service from the cloud, it takes care of the complexity of running a communications infrastructure including the NAT traversal mechanisms. Mission critical and real-time voice and video services where the endpoints have private and public IPv4 addresses are easy to build with the feature-rich APIs.
The iotcomms.io SIP Server handles NAT Traversal
The NAT Traversal complexity is handled in the iotcomms.io SIP Server. Build reliable mission critical voice and video services without having to bother about the complexity of SIP devices sitting behind a NAT.
