Version 5.1

Introduction Installation SysAdmin Network Objects E-mail Signals Access Services Directory Clusters Applications Miscellaneous Licensing   WebMail PBX

Overview Rules SIP XMPP PSTN NAT Media NAT Traversal NAT Traversal and Media Stream Proxy Near-End NAT Traversal Far-End NAT Traversal Edge Services The "original, "basic" VoIP communication model assumes that endpoints can communicate directly, i.e. that all "entities", including 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 in located somewhere in the WAN. one endpoint is located behind a remote NAT, while the other one is not locate behind the same NAT. one endpoint is located in 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 end to a remote entity.

NAT Traversal and Media Stream Proxy

The "basic" communication model assumes that endpoints can communicate directly, i.e. that all "elements", including 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 signalling requests are sent directly between the endpoints:

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:

The CommuniGate Pro SIP Module detects session re-INVITE requests as well as BYE requests and update and removes the session 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 Stream Proxy functionality, make sure that the LAN and NAT data is specified correctly on the LAN IPs settings page.

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

Far-End NAT Traversal

The CommuniGate Pro SIP Module also provides the "far-end" NAT traversal capabilities by detecting requests coming from clients located behind remote Firewall/NATs.
The Module adds appropriate Record-Route and Path headers to these requests and it builds media proxies to relay traffic to and from those clients.

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.

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.

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