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:
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.