The SIP module parses all received SIP packets, and uses the module subcomponents to
process the parsed packets. Request packets are submitted to the SIP Server subcomponent, to a new SIP Server
transaction or to an existing one.
The SIP Server component uses the Signal Module to process the request. The responses generated with the Signal module are submitted to the SIP Server transaction, and the SIP Server sends them back to the source of the SIP request.
The Signal module can send a Request to a remote SIP device or to a remote SIP server. The module uses the SIP Client subcomponent to create a SIP Client transaction. This transaction is used to send a SIP Request via an Internet protocol, and to process the Responses sent back.
SIP Request packets received with the SIP Module are submitted to the SIP Server subcomponent, while SIP Response packets are submitted to the SIP Client subcomponent, with two exceptions:
The CommuniGate Pro SIP module supports UDP and TCP communications, and it also supports secure (TLS) communications over the TCP protocol.
The CommuniGate Pro SIP module supports near-end and far-end NAT traversal, enabling SIP communications for both large corporations with many internal LANs, as well as for home users connecting to the Internet via "dumb" NAT devices.
The session initiation schema described above works correctly only if both parties can communicate directly. If there is a firewall or a NAT device between the parties, direct communication is not possible. In this case, the CommuniGate Pro SIP module builds and manages media proxies, relaying not only the SIP protocol requests and responses, but the actual media data, too.
Click the Receiving link to open the SIP Server (UAS) Settings.
The Transport panel allows you to configure the network-level options for SIP packet receiving:
The Transactions panel allows you to specify how the SIP Module handles SIP server (UAS) transactions.
The SIP Module server component implements Request Authentication for remote clients. If an internal Server component rejects a Request because it does not contain authentication data, the Module adds special fields to the response it sends, facilitating authentication.
The user name specified in the authentication data is processed using the Router
component, so Account Aliases and Forwarders, as well as Domain Aliases can be used in authentication names.
The specified Account and its Domain must have the SIP Service enabled.
All CommuniGate Pro Account passwords can be used for SIP authentication.
The Transport panel allows you to configure the network-level options for SIP packet sending:
The Transactions panel allows you to specify how the SIP Module handles SIP client (UAS) transactions.
Note: if you use an in-house PSTN gateway, it is usually configured to accept all calls from within your LAN (so your Server does not need to use Authentication to relay call Signals to that gateway), and that gateway can be configured to direct incoming connections to a certain CommuniGate Pro Server Account (so there is no need to register your Server with that gateway). In this case you can employ this PSTN gateway without using the External Gateways features.
Use the External Gateway panel to specify the Gateway settings:
To create a new External Gateway entry, enter the Gateway Name in the last, empty table element, and click the Update button.
To remove an External Gateway entry, enter an empty string into its Gateway Name field, and click the Update button.
In order to send Signal requests to the External Gateway, you need to specify Router records.
Use the following Router records:
NoRelay:Signal:<1*> = *@Provider1.sipgw NoRelay:Signal:<+1*> = *@Provider1.sipgw NoRelay:Signal:<+*> = 011*@IntlProvider.sipgw NoRelay:Signal:<011*> = 011*@IntlProvider.sipgw NoRelay:Signal:<9*> = 415*@LocProvider.sipgw
Note: you should use the NoRelay: prefix to avoid turning your Server into an open relay that would allow any external user to relay calls to the External Gateway using your Server credentials.
The "original, "basic" SIP communication model assumes that endpoints can communicate directly, i.e. that all "elements", including SIP clients - phones, softphones, PBX applications), and SIP servers have "real" Internet IP Addresses. In this situation the Server (SIP Proxy) is needed only to establish a call. Media data and in-call signalling requests are sent directly between the endpoints:
CommuniGate Pro supports automatic "NAT traversal" for the standard-based real-time communications.
The CommuniGate Pro SIP Module detects 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:
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.
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:
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.
The Windows Messenger versions prior to 5.0 are not supported.
The CommuniGate Pro SIP module should have the Advertise NTLM option enabled.
The Windows Messenger audio and video sessions use standard RTP media protocols and these sessions
can be used over a NAT/Firewall.
The Windows Messenger Instant Messaging uses the SIP protocol for media transfer and Instant Messaging sessions can be used over a NAT/Firewall.
The Windows Messenger Whiteboard, Application Sharing, and Remote Assistance sessions use T.120 and non-standard protocols and these sessions can be used over a NAT/Firewall.
The Windows Messenger File Transfer sessions use a non-standard protocol and these sessions currently cannot be used over a NAT/Firewall.
Open the SIP Module settings and click the Workarounds link. A table appears:
To specify workarounds for a certain product, put the product name into the last, empty Table element, select the required workarounds and click the Update button.
To remove a certain product, remove its name from the table, and click the Update button.
A similar table exists for remote sites:
When the SIP module is about to relay a Signal request to a remote destination, it applied the workaround methods specified for the request URI domain as well as the methods specified for the target URI domain.
The currently implemented workaround methods are:
The following Web Site contains a periodically updated document listing the tested SIP Clients, the problems discovered and the known workarounds.
The SIP module immediately (on the first Router call) accepts all signal addresses with IP-address domains, i.e. with domain names like [xx.yy.zz.tt]. Please note that the Router adds brackets to the IP-address domain names that do not have them, and the Router changes the IP addresses of local domains to those domain names. The Router performs these operations before calling the modules.
The SIP module immediately accepts all signal addresses with domain names ending with the .sipgw suffix. The rest of the domain name should specify the name of an External Gateway and the Signal is routed to that External Gateway.
On the final call, the SIP module accepts signal to any domain if that domain name contains at least one dot (.) symbol. If the Relay via option is selected, all these addresses are rerouted to the specified Relay via domain.
Before accepting an address, the SIP module checks if the address does not contain any @ symbol, but contains one or several % symbols. In this case, the rightmost % symbol is changed to the @ symbol.
If the target domain name contains a .udp, .tcp, or .tls suffix, the corresponding transport protocol is used, and the suffix is removed from the target domain name.
The SIPS frame displays the active SIP Server transactions:
The SIPC frame displays the active SIP Client transactions: