CommuniGate Pro
Version 6.3
 

NAT Traversal

The "original, "basic" VoIP communication model assumes that endpoints can communicate directly, i.e. that all "entities", both clients (phones, softphones, PBX applications) and servers have "real" Internet IP Addresses. In this situation the entities can exchange media data directly, sending media packets (usually using the RTP or T.120 protocols) directly to each other.

The real-life situation is quite different from this model, and media data cannot be sent directly between endpoints. The CommuniGate Pro Server solves this problem by automatically creating Media Proxies and instructing endpoints to send media data to that Media Proxy for relaying.

A Media Proxy is created when:
  • one endpoint is connected to the LAN, while the other one is located somewhere within the WAN.
  • one endpoint is located behind a remote NAT, while the other one is not located behind the same NAT (see the option below).
  • one endpoint is located within an IPv4 network, while the other one is located in the IPv6 network.
  • the Signal component explicitly requested creation of a Media Proxy.

Media Proxies are created with the SIP and XIMSS components when a call is being sent to a remote entity.

NAT Traversal and Media Stream Proxy

The "basic" communication model assumes that endpoints can communicate directly, i.e. that all "entities", both clients (phones, softphones, PBX applications) and servers have "real" Internet IP Addresses. In this situation the Server is needed only to establish a call. Media data and (in case of SIP) in-call signaling requests are sent directly between the endpoints:

Basic SIP Call

In the real life, many clients are located in remote LANs ("behind a NAT"), or in different LANs so they cannot communicate directly. CommuniGate Pro supports automatic "NAT traversal" for the standard-based Real-Time communications.


Near-End NAT Traversal

The CommuniGate Pro SIP and XIMSS Modules detect the session initiation requests that are sent from one side of NAT to the other side (a request from a LAN client to a party on the Internet/WAN and vice versa). In this case, the Server uses some local server port (or a set of ports depending on the media protocol(s) used) to build a media stream proxy. The Server then modifies the session initiation request to direct the traffic from both sides to that proxy.

The Media Proxy relays media data between the "LAN leg" and the "WAN leg" of the media connection:
Near End NAT SIP Traversal

The CommuniGate Pro SIP and XIMSS Modules detect session update (SIP re-INVITE) and session close (SIP BYE) requests and update and remove the Media Proxies accordingly. The time-out mechanism is used to remove "abandoned" Media Proxies.

The CommuniGate Pro provides NAT proxy services for:
  • UDP media protocols
  • RTP media protocols based on UDP
  • TCP media protocols
  • T.120 media protocols based on TCP

Note: If you need the Media Proxy functionality, make sure that the LAN and NAT data is specified correctly on the LAN IPs and NAT WebAdmin settings pages.

Note: The Server automatically builds Media Proxies when it relays requests from IPv4 addresses to IPv6 addresses and vice versa.


Far-End NAT Traversal

The CommuniGate Pro SIP and XIMSS Modules also provide the "far-end" NAT traversal capabilities by detecting requests coming from clients located behind remote Firewall/NATs.
The Modules add appropriate Record-Route and Path headers to these requests and they build Media Proxies to relay traffic to and from those clients.

Far End NAT SIP Traversal

Note: modern SIP clients support various NAT traversal methods (STUN, etc.). Many of these implementations are quite buggy, so it is often more reliable to switch the client-side NAT traversal methods off, and rely on the CommuniGate Pro SIP Module far-end NAT traversal capabilities instead.

Note: due to the nature of the TCP protocol and the Firewall concept, it is not possible (in general) to open a TCP connection to a client behind a far-end NAT ("near-end" NAT configurations do not have this problem). This means that clients behind a far-end NAT cannot initiate TCP (T.120) sessions.

To solve this problem, you may want to:
  • always initiate TCP sessions from a client that is not behind a far-end NAT/Firewall (these clients accept those invitations and start outgoing TCP connections without a problem)
    or
  • use an additional copy of the CommuniGate Pro Server on that remote location as a near-end NAT traversal solution for that network, eliminating a need for far-end NAT traversal on the "main" CommuniGate Pro server
    or
  • configure the remote Firewall/NAT to relay all incoming TCP request to the T.120 port (usually, the port 1503) to a particular workstation behind that Firewall.

Edge Services

The CommuniGate Pro SIP Module can be used as an "Edge Service" or ALG ("Application Level Gateway"), providing NAT traversal functionality for users registered on other servers.

SIP Edge Services

The CommuniGate Pro SIP Module detects "media loops", when a call placed from within LAN is proxied to WAN, and then proxied back to the same LAN. In this case the Media Proxies are removed, eliminating unnecessary overhead, and allowing SIP clients to communicate directly within one LAN, while proving registrar services outside that LAN.

Collapsing Media Proxy

The SIP module can detect much more complex loop cases, either avoiding Media Proxies altogether, or minimizing the number of Media Proxies used.


NATed Addresses

To detect clients located behind NATs, the Server needs to know which addresses are used on remote networks behind those NATs.
Use the WebAdmin Interface to specify the NATed Addresses. Open the Network pages in the Settings realm, then open the NATed IPs page.

NATed IP Addresses

If a SIP client sends a request to CommuniGate Pro and the client own network address specified in the request headers is included into the NATed IP Addresses list, while the Server has received this request from a different network address, NOT included into the NATed IP Addresses list, the Server decides that this client is behind a NAT.


NAT Systems

Some NAT servers make attempts to perform "SIP application gateway" functions, changing the IP addresses specified in the relayed SIP requests.
Many of those NAT servers fail to perform these gateway functions correctly, and CommuniGate Pro should treat clients connecting via those NAT servers using its "far-end NAT traversal" functionality, but CommuniGate Pro cannot detect that this functionality is needed, because the client IP addresses specified in their SIP requests are damaged.
You can specify the IP addresses of those broken NAT servers in the NAT Server IP Addresses field: all requests coming from the specified Network Addresses are treated as requests from "NATed" clients:

NAT Server IP Addresses

You may need to relay requests to remote SIP servers (such as PSTN gateways) located behind a far-end NAT. Since these servers do not issue SIP REGISTER requests to your CommuniGate Pro Server, there is no way to automatically detect these far-end NAT traversal situations.
Include the public Network IP Addresses of these remote SIP servers into the NAT Server IP Addresses field to instruct the CommuniGate Pro SIP Module to use far-end NAT traversal techniques when starting sessions with these SIP servers.

When clients connect to the CommuniGate Pro server from behind multi-homed NAT servers, the client Signal (SIP, XIMSS) connections and media (RTP) streams can come from different IP Addresses.
When a client uses HTTP transactions to connect to WebUser or XIMSS session, the HTTP requests coming from multi-homed NAT servers can come from different IP Addresses.
In thess situations clients can experience lack of media transfer or rejection of session requests caused by a "wrong IP Address" problem.

To avoid this problem, two different IP Addresses are treated as the "same address" if both of them are included into the same IP Address range in the NAT Server IP Addresses list.


Pinger

To send incoming calls to a SIP client behind a NAT, CommuniGate Pro keeps the "communication hole" between the client and Server open by periodically sending dummy packets to that client.

NATed Clients Pinger
Log Level: Clients Limit: Ping Clients every:UDP:
  TCP:
Log Level
Use this setting to specify what kind of information the NAT Pinger component should put in the Server Log. Usually you should use the Major or Problems (non-fatal errors) levels.
The NAT Pinger component records in the System Log are marked with the NATPING tag.
Clients Limit
Use this setting to specify how many different NAT clients the Server can ping.
Ping Clients Every
Use this setting to specify how often the Server should send its "pinging" packets to its clients using UDP and TCP protocols.

Media Proxy

CommuniGate Pro supports various real-time communications. Most of those real-time protocols cannot be used via a NAT/Firewall, so CommuniGate Pro can act as "proxy" for those protocols.

When a client on the LAN tries to communicate with a remote system on the Internet (WAN), CommuniGate Pro creates a Media Proxy - a communication port on its own system.
It forces the client to connect to that Media Proxy instead of the remote system media port.
The CommuniGate Pro Media Proxy communicates with the remote system itself, relaying the data received from the LAN client to the remote system and vice versa.

A Media Proxy is created to serve entries (users) located behind remote NAT devices.

A Media Proxy is created to relay traffic between an IPv4 and IPv6 entries.

Media Proxy
Log Level: UDP TOS Tag:
Source Port Restriction: Relay for clients behind the same NAT:
Log
Use this setting to specify what kind of information the Media Proxy component should put in the Server Log. Usually you should use the Major or Problems (non-fatal errors) levels. But when you experience problems with the Proxy component, you may want to set the Log Level setting to Low-Level or All Info: in this case protocol-level or link-level details will be recorded in the System Log as well.
The Media Proxy component records in the System Log are marked with the MEDIAPROXY tag.
A Media Proxy can create zero, one or several stream proxies for each media stream (for example, one stream proxy for the audio stream, and one - for the video stream). Stream proxy records in the System Log are marked with UDPPROXY or the TCPPROXY tag.
Source Port Restriction
When this option is selected, the UDP-based media from external non-NATed sources is accepted only when it comes from the correct IP address and port number.
When this option is not selected, only the media source IP address is checked. This helps to serve certain broken devices that send SDP data with incorrectly specifed media port numbers.
UDP TOS Tag
Unless this option is set to OS default, the UDP-based media packets get the specified TOS (type of service) tag value. This may help you prioritize the media traffic if your network infrastructure assigned a higher priority to packets with the specified TOS tag.
Relay for clients behind the same NAT
When two endpoints are located behind the same far-end NAT (i.e. when their visible, external Network IP Addresses are the same), this option specifies if a Media Proxy should be built to relay media between these endpoints.
Never
Media Proxy is not built for these endpoints. Use this option when you expect that endpoints behind the same NAT IP can communicate directly.
NAT Sites
Media Proxy is built for these endpoints if their visible Network IP Address is included into the NAT Server IP Addresses list.
Always
Media Proxy is always built for these endpoints.

Note: some remote NAT systems are "multihomed". In this case, a signaling request can come from one external IP Address of that system, while the media stream may come from a different IP Address.
CommuniGate Pro Media Proxies can support these NAT systems if all their external IP Addresses are included into a single IP Address range, and if this IP Address range is included into the NAT Systems list.


CommuniGate Pro Guide. Copyright © 2020-2023, AO StalkerSoft