SIP Module

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:

• if no Client transaction can be found for a Response packet, the packet is relayed "upstream" by the SIP Module itself, without using the Signal module.
• if no Server transaction can be found for an ACK Request, a SIP Client transaction is created to relay the ACK Request "downstream".

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 media data, too.

Log Level

Use this setting to specify the type of information about SIP packets and SIP transport the module should put in the Server Log. Usually you should use the Failure (unrecoverable problems only), Major (session establishment reports), or Problems (failures, session establishment and non-fatal errors) levels.
When you experience problems with the SIP module, you may want to set the Log Level setting to Low-Level or All Info: in this case the packet contents and other details will be recorded in the System Log. When the problem is solved, set the Log Level setting to its regular value, otherwise your System Log files will grow in size very quickly.
The SIP module transport records in the System Log are marked with the SIPDATA tag.
Generic SIP information records have the SIP tag.

UDP

To configure the UDP transport, click the UDP listener link. The UDP Listener page will open. By default, the SIP UDP port is 5060.

TCP

To configure the TCP transport, click the TCP listener link. The TCP Listener page will open. There you can specify both secure and clear-text TCP ports. By default, the clear-text SIP TCP port is 5060, and the SIP TLS port is 5061.

Input Channels

Use this option to specify the maximum number of TCP communication channels the module can open. If the number is exceeded, the module will reject new incoming TCP connections.

Idle Timeout

Use this option to specify when the SIP module should close a TCP communication channel if there is no activity on that channel. This helps to reduce the resources used for TCP communication channels on large installations. On the other hand, some SIP clients may not function properly if the server closes its TCP connection on a time-out.

Enqueuers

When this option is set to a non-zero value, received packets are not processed immediately: they are placed into a special queue and the receiving thread becomes ready to receive a new packet immediately. The option specifies a number of additional threads that take packets from that queue and process them, sending them to Server or Client SIP transactions.

Enqueued Limit

When packets are not processed immediately, but placed into a special queue first (see above), this option limits the size of that queue. When the number of packets in the queue exceeds this limit, new received packets are dropped. You may want to increase the number of Enqueuers in this situation.

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.

Advertise Digest AUTH

Select this option to inform SIP clients that the standard DIGEST authentication method is supported.

Advertise Digest NTLM

Select this option to inform SIP clients that the non-standard NTLM authentication method is supported.

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.

If the CommuniGate Password option is enabled for the specified Account, the SIP module checks if the Account has the SIPPassword setting. If it exists, it is used instead of the standard Password setting. This feature allows an Administrator to assign a alternative Account password to be used for the SIP authentication only.

Send '100 Trying' for non-INVITEs

If this option is enabled and the client resends a request, the SIP module sends the 100 ("Trying") response even in the request method is not INVITE.

Always Send '100 Trying' for INVITEs

If this option is enabled, the SIP module always sends the 100 ("Trying") response before it starts to process an INVITE request.

Force Dialog Relaying

If this option is disabled, the SIP Module introduces itself only into those SIP dialogs that require its participation (such as those involving NAT/Firewall traversal). If this option is enabled, the SIP module introduces itself into all SIP dialogs opened. This feature can be used for troubleshooting, as all details of dialog transactions are recorded in the Server Log.

Relay to Non-Clients

If this option is set to anybody, the SIP Module acts as an Open Relay: it relays any SIP request to any destination.
To prevent abuse of your Server, allow relaying for clients only or for nobody.
The SIP Module will send Requests if at least one the following conditions is met:

• the destination address is listed as a Client IP address.
• the Request is being relayed to devices registered with some Account on your Server.
• the Request is generated by a Local Node (such as a PBX Task).
• the Request sender is authenticated with your Server.
• the Request is received from a network address listed in as a Client IP address (only if this option is set to clients).

If none of these conditions is met, the request is rejected with the 401 ("Authentication required") error code.

Relay via

Enable this option if you want to relay all outgoing packets via some external SIP server. Note that this setting is not used for addresses explicitly routed to external hosts using the .via suffix or other routing methods.

Timer B

This option controls the value of the "Timer B" (specified in RFC3261). It controls the maximum time the INVITE-type transaction will wait for any first response from the called party.
While the standard specifies the 32 seconds value, we strongly recommend to lower this value to 5-10 seconds: if the remote party does not provide any answer within that time (not even the 100-Trying response), most likely it is down and there is no need to wait for 32 seconds before reporting this to the call originator.
Lowering this time allows the SIP Client transaction to try other SRV records (if any exists): if this timer is set to 32 seconds, the calling user is likely to give up before the next SRV record is tried.

Send P-Asserted-Identity

If this option is enabled, and the request sender is authenticated, a P-Asserted-Identity field is added to the SIP request sent. The field contains a SIP URI with the authenticated Account full name (sip:accountName@domainName).

Gateway Name

Use this setting to assign an internal name to this External Gateway. You will use that name in the Router records to address certain calls to this Gateway. Assign a unique alphanumeric name to each External Gateway you will use.

Domain

Use this setting to specify the External Gateway domain name.

Via

Use this setting if the requests for this External Gateway should not be sent to the network addresses associated with the Gateway Domain name (for example, requests sent to this Gateway should be sent via some proxy).
This setting allows you to specify an alternative domain (DNS) name, an IP address, or a complete SIP URI.

Username

Use this setting to specify a name to be used to register on and (optionally) to call via this External Gateway.
If the value does not contain the @ symbol, the Domain setting is added to form a quialified username.

Password

Use this setting to specify the password to use with the External Gateway.

AuthName

Specify this setting only when the Authentication name to be used with the External Gateway is not the same as the UserName.

Register every

Use this setting to specify how often the SIP Module should send REGISTER Requests to this External Gateway.

Contact

Use this setting to specify the address to be registered with the External Gateway. When a gateway receives an incoming call, it sends the call Signal request to the specified address.
This Contact address usually is an Account on your Server that employs an "auto-attendant" Real-Time Application to answer these calls and to direct them to other Accounts on your Server.

Calls: Authenticate

When this option is not disabled, an authentication header field (Authorization or Proxy-Authorization) is added to all call (INVITE) requests sent to this External Gateway. The Module employs the authentication "nonce" used for the last REGISTER request sent to the Gateway, so make sure your Register Every time period is shorter than the nonce "Time To Live" period of this External Gateway.

Calls: Substitute From

When this option is selected, the From addresses (the caller name and address) of the call (INVITE) requests are substituted with the Username (caller masquerading).

Calls: Substitute To

When this option is selected, the To addresses (the callee name and address) of the call (INVITE) requests are substituted with the Signal request URI (after removing URI port number and URI parameters).

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.

Sample 1.

All calls to 1number@main_domain should be directed to the Provider1 Gateway as requests to call number
All calls to +1number@main_domain should be directed to the Provider1 Gateway as requests to call number
all calls to +number@main_domain (where number does not start with 1) should be directed to the IntlProvider Gateway as requests to call 011number
all calls to 011number@main_domain should be directed to the IntlProvider Gateway as requests to call 011number
all calls to 9number@main_domain should be directed to the LocProvider Gateway as requests to call 415number

Use the following Router records:

NoRelay:Signal:<1*>   = *@Provider1.sipgw
Signal:<+1*>  = *@Provider1.sipgw
Signal:<+*>   = 011*@IntlProvider.sipgw
Signal:<011*> = 011*@IntlProvider.sipgw
Signal:<9*>   = 415*@LocProvider.sipgw

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.

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 Monitors realm of the WebAdmin Interface allows Server Adminstrators to monitor the SIP module activity. The SIP Monitor page contains two frames - the receiving (Server) frame, and the sending (Client) frame.

The SIPS frame displays the active SIP Server transactions:

The SIPC frame displays the active SIP Client transactions: