| Version 5.4
Introduction
Installation
SysAdmin
Network
Objects
Storage
E-mail
Real-Time
Access
Services
Directory
Clusters
Applications
Miscellaneous
Licensing
WebMail
Pronto!
PBX
Overview | Rules | IM & Presence | SIP | XMPP | SMPP | PSTN | NAT | Media | Parlay
# SIP Module Session Initiation Protocol (SIP) SIP Server Settings SIP Client Settings Microsoft® Windows Messenger Support SIP Devices Support and Workarounds Routing Monitoring SIP Activity The CommuniGate Pro SIP Module implements the SIP Internet protocols via IP networks. The module is used to receive Signal Requests from remote entities, and to send Signals to remote entities. The SIP protocol does not include the protocols required for actual data transfer (media transfer protocols). Instead, the SIP protocol allows all participating parties to find each other on the network, to negotiate the media transfer protocol(s) and protocol parameters, to establish interactive real-time sessions, and to manage those sessions: add new parties, close sessions, update session parameters, etc.

## Session Initiation Protocol (SIP)

The CommuniGate Pro SIP Module implements the SIP protocol functionality. The module uses TCP and UDP listeners to receive SIP request and response packets via these network protocols. It also sends the response and request packets via the TCP and UDP network protocols.

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.

## SIP Server Settings

Use the WebAdmin Interface to configure the SIP module. Open the Real-Time pages in the Settings realm, then open the SIP pages.

Click the Receiving link to open the SIP Server (UAS) Settings.

### Transport

The Transport panel allows you to configure the network-level options for SIP packet receiving:

Transport
Log Level: |  | UDP Listener |
Enqueuers: |  | TCP Listener | Channels: |
Enqueued Limit: |  | Idle Timeout: |

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

### Transactions

The Transactions panel allows you to specify how the SIP Module handles SIP server (UAS) transactions.

Server Transactions
Log Level: | Processors: | Object Limit: | Event Limit:

`Log`
  Use the Log setting to specify what kind of information the SIP Server subcomponent 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.
  The SIP Server subcomponent records in the System Log are marked with the SIPS tag.
`Processors`
  Use this setting to specify the number of threads used to process SIP Server transactions.
`Object Limit`
  Use this setting to specify the maximum number of concurrent server transactions the SIP Module is allowed to handle. When this number is exceeded, incoming SIP packets with new requests are dropped.
`Event Limit`
  Use this setting to specify the maximum number of unprocessed events sent to all active SIP server transactions. If this number is exceeded, the SIP Server component is overloaded: no new SIP server transactions can be created, and incoming SIP packets with new requests are dropped.

### Protocol

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.

Protocol
Advertise 'Digest' Authentication | Advertise 'NTLM' Authentication
Send '100 Trying' for non-INVITEs | Always Send '100 Trying' for INVITEs

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

### Protection

The SIP Module server component implements several protection techniques:

- UDP packets and TCP connections from Network IP Addresses included into the Denied Addresses list are dropped without processing.
- When the number of misformed SIP packets received from some Network IP Address address exceeds the specified frequency limit, that Address is added to the Temporarily Blocked Addresses list.
- When a SIP request is rejected because of some authentication error, the response is sent after some delay, and the sender Network IP Address is added to the Temporarily Blocked Addresses list if the number of the authentication errors associated with that Address exceeds the specified frequency limit.
- When a SIP request received from Network IP Addresses included into the Temporarily Blocked Addresses list, they are dropped without processing.

## SIP Client Settings

Use the WebAdmin Interface to configure the SIP module. Open the Real-Time pages in the Settings realm, then open the SIP pages.

Click the Sending link to open the SIP Client (UAC) Settings.

### Transport

The Transport panel allows you to configure the network-level options for SIP packet sending:

Transport
Log Level: |  | UDP Request Size Limit: | LAN: |
UDP TOS Tag: |  | WAN: |
Use Short Field Names: |  |

`Log`
  Use this setting to specify the type of information about SIP packets and SIP transport the module should put in the Server Log.
  This is the same settings as the Transport Log Level setting displayed on the SIP Server settings page.
`UDP Request Size Limit`
  Use this option to specify the size for the largest UDP packet that can be sent within your LAN and outside your LAN. If the SIP module needs to deliver a packet and the protocol is not explicitly specified, the SIP module uses the UDP protocol, unless the packet size is larger than the specified limit. In the latter case the TCP protocol is used.
`UDP TOS Tag`
  Use this setting to specify the TOS tag for all outgoing SIP UDP packets. This tag can be used to set the SIP traffic priority on your LAN.
`Use Short Field Names`
  If this option is enabled, all SIP packets (client requests and server responses) the Server generates will use alternative (1-symbol) packet header field names. You may want to enable this option to decrease packet sizes.

### Transactions

The Transactions panel allows you to specify how the SIP Module handles SIP client (UAS) transactions.

Client Transactions
Log Level: | Processors: | Object Limit: | Event Limit:

`Log`
  Use the Log setting to specify what kind of information the SIP Client subcomponent 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.
  The SIP Client subcomponent records in the System Log are marked with the SIPC tag.
`Processors`
  Use this setting to specify the number of threads used to process SIP Client transactions.
`Object Limit`
  Use this setting to specify the maximum number of concurrent client transactions the SIP Module is allowed to handle.
`Event Limit`
  Use this setting to specify the maximum number of unprocessed events sent to all active SIP client transactions. If this number is exceeded, the SIP Client component is overloaded, and no new SIP client transactions can be created.

### Protocol

Protocol
Force Dialog Relaying | Relay to Any IP Address for: |
Relay via: | Timer B: |
Send P-Asserted-Identity |

`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.
`487-Wait Timer`
  When a SIP transaction is client, a CANCEL request is generated and sent. This setting specifies for how long the Module should wait for a 487-response from the client.
  If no response is received, the Module generates the 487-response itself.
`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`).

## Microsoft® Windows Products Support

The Microsoft "RTC" products (including Windows Messenger) use the standard SIP protocol for audio and video sessions.
These clients use the proprietary SIP protocol extensions for Instant Messaging, Presence, Whiteboard, Remote Assistance and other services. CommuniGate Pro implements the extensions required to support these applications.

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.

## SIP Devices Support and Workarounds

Many currently available SIP devices and applications incorrectly implement various aspects of the SIP protocol.
The CommuniGate Pro SIP Module tries to compensate for certain client problems and bugs, based on the type of SIP devices connected to it.

Use the WebAdmin Interface to configure the SIP workarounds. Open the Real-Time pages in the Settings realm, then open the SIP pages. Click the Workarounds link. The Workarounds table appears:

Problems/Bugs
Agent Name | Microsoft | SubPresence | FixContacts | NoTCP | NoMaddr | NoPath | BadByeAuth | NeedsEpid | NoSubMWI
--- | --- | --- | --- | --- | --- | --- | --- | --- | ---

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:

Problems/Bugs
Agent Name | Microsoft | SubPresence | FixContacts | NoTCP | NoMaddr | NoPath | BadByeAuth | NeedsEpid | NoSubMWI
--- | --- | --- | --- | --- | --- | --- | --- | --- | ---

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:

`Microsoft`
  The entity is a Microsoft client. Protocol messages are signed, and other SIP protocol derivations are processed.
`SubPresence`
  The entity supports Presence, but does not implement a push-type Presence Agent (`Publish`). The Server will send `SUBSCRIBE` requests to monitor the entity Presence status.
`noTCP`, `noMaddr`
  The entity does not support `transport` and/or `maddr` Contact parameters. The Server will modify the Contact data sent to this entity.
`noPath`
  The entity does not support the RFC3327 (`Path` fields).
  The Server will modify the Contact data sent to this entity.
`badByeAuth`
  The entity incorrectly calculates Authentication digests for non-INVITE (`BYE`, `NOTIFY`, `REFER`) requests.
`needsEpid`
  The entity uses a non-standard `epid=` parameter in its From/To URIs and fails to work if the peer does not preserve this non-standard parameter.
`NoSubMWI`
  The entity uses supports the Message-summary Event package (to implement MWI - Message Waiting Indicator), but it fails to send SUBSCRIBE requests to activate this service.
  The Server will subscribe the client on registration.

The following Web Site contains a periodically updated document listing the tested SIP Clients, the problems discovered and the known workarounds.

## Routing

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.

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.

## Monitoring SIP Activity

The Monitors realm of the WebAdmin Interface allows Server Administrators 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:

| 2 of 2 selected

ID | Status | Msg | Phase | Source | Target |
--- | --- | --- | --- | --- | --- | ---
38984 | waiting (15s) | 0 | completed | udp[10.10.0.226:59645] | SIGNAL-40726 | OPTIONS sip:ns.communigate.com
38994 | waiting (7s) | 0 | completed | tcp[10.0.14.193:24777] | SIGNAL-40734 | MESSAGE sips:user@communigate.com

The SIPC frame displays the active SIP Client transactions:

| 2 of 2 selected

ID | Status | Msg | Phase | Source | Target |
--- | --- | --- | --- | --- | --- | ---
35184 | waiting (2m) | 0 | provisioned | SIGNAL-40726 | udp[10.0.1.34:5060] | INVITE sip:user@10.0.1.34:5060
35188 | waiting (7s) | 0 | request sent | SIGNAL-40732 | udp[10.0.1.34:5060] | MESSAGE sips:user@communigate.com

CommuniGate® Pro Guide. Copyright © 1998-2012, Stalker Software, Inc.