CommuniGate Pro
Version 5.1
Signals
 
 
 
SIP

SIP Module

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:

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 UDP TOS Tag:
Enqueuers: TCP Listener Channels:
Enqueued Limit: Idle Timeout:
Log
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.
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.
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.

Transactions

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

Server Transactions
Log Level: Limit: Processors:
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.
Limit
Use this setting to specify the maximum number of concurrent server transactions the SIP Module is allowed to handle.
Processors
Use this setting to specify the number of threads used to process SIP Server transactions.

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.


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

Transactions

The Transactions panel allows you to specify how the SIP Module handles SIP client (UAS) transactions.
Client Transactions
Log Level: Limit: Processors:
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.
Limit
Use this setting to specify the maximum number of concurrent client transactions the SIP Module is allowed to handle.
Processors
Use this setting to specify the number of threads used to process SIP Client transactions.

Protocol

Protocol
Force Dialog Relaying Relay to Any IP Address for:
Relay via: Timer B:
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.

External Gateways

You may want to use your CommuniGate Pro Server with external SIP Gateways. External Gateways can be used to relay calls to the public telephony network (PSTN) and to relay PSTN calls to your Server. These services are usually fee-based and communications with External Gateways may require authentication.
You can also use the External Gateways features if you need to communicate with remote SIP networks using authentication.

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:
GatewayName: Calls: Authenticate:
Domain: Via: Proxy:
Username: Substitute: From To
AUTH Name: Contact:
Password: Register Every:
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
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.


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 MicrosoftSubPresenceFixContactsNoTCPNoMaddrNoPathBadByeAuthNeedsEpidNoSubMWI

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 MicrosoftSubPresenceFixContactsNoTCPNoMaddrNoPathBadByeAuthNeedsEpidNoSubMWI

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.

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.


Monitoring SIP Activity

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:

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

The SIPC frame displays the active SIP Client transactions:

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

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