Configuration - Clustering

For reliability reasons (see below), Sytel limits the number of voice channels that may be handled by one STG process / server instance to 1000.

For basic inbound calls to agents or preview / progressive outbound, this equates to around 450 calls per process / server - one channel for the agent connection, one for the contact connection with some additional channels (~10%) reserved for call queuing and IVR.

For predictive dialing, the number of outbound channels required will depend on the dialing rate. This can typically be 2 or 3 times the number of agents (or higher for very low connect rates).

Call transfers, conferencing and other functions that require additional voice channels will add to the channel usage.

In practice, Sytel recommends a clustered configuration for any users deploying more than 100 agent endpoints (whether human or IVR).

See also Softdial Telephony Gateway™ Configuration Issues

As a general rule, the more processing that is pushed through a single processing node, the greater the likelihood of failure.

This increased likelihood of failure is exponential rather than linear, which is why Sytel specify a maximum of 1000 voice channels per STG process.

By sharing the processing load over two or more processes, system reliability is improved.

The cost of failure is similarly reduced; loss of productivity is limited to:

number of failed nodes / total number of nodes * 100 %.

There are many deployment models for clustering. The 3 most common models are described below:

1. Large, Single Virtual Telephony Node
   This involves running several identical STG servers configured as an N+1 redundant cluster. The default load-balancing algorithm configured in the Python script is designed for this configuration.
2. International Operation With Local Voice Points of Presence (POPs)
   In a multi-site installation, there may be agents and trunk interfaces located in different countries. In each country, one might deploy a redundant pair of STG servers but manage clustering centrally. In this way, default behaviour would be to have agents tied up to their local POP and calls made to the customer through the same POP. However, it would also facilitate an agent in one country dialing a call through an STG in another country to get local call charging, and using the corporate WAN to carry the bridging voice call between STG servers in different countries.
3. Dedicated Resources For Specific Tenants
   In a hosted scenario, a carrier may have many small tenants sharing telephony resources and a few larger tenants. The larger tenants may mandate uncontended (and redundant) telephony media processing, and may insist on routing incoming call traffic to a specific host or pair of hosts dedicated to them. In this case, the clustering logic may be configured to separate out calls for specific tenants.

To configure a campaign to use a cluster of STGs or a single STG: in the Softdial Campaign Manager™ Client, on the Telephony Setup tab/ page, set the CT Layer Identifier (Fig. 2):

Fig. 2 - CT Layer Identifier

In this example, STG_Cluster1 can either be a single STG or a cluster of STGs.

By default, a single STG instance runs as a standalone cluster.

To configure multiple STGs as a single cluster:

In the config.xml file of every STG that will be part of a cluster, set the following tags:

1. <clusterMode>true</clusterMode>
   <telephonyLayerID>STG_Cluster1</telephonyLayerID>
   
   Each STG within a cluster should have the same layer ID. This layer ID is the string value specified in the Softdial Campaign Manager™ Client to assign a campaign to a single STG or a cluster of STGs as shown in Fig. 2.
   
   A default CTI layer with ID of __singlecti is required for tenant provisioning. Make sure there is one CTI layer with this default ID in your configuration.
2. <telephonyLayerIP>x.x.x.x</telephonyLayerIP>
   
   This tag should be set to the IP address (or the machine name) of the machine to enable successful bridging of the calls within a cluster. This tag is important because it allows various STG nodes in a single cluster to communicate with each other directly, e.g. when the agent is nailed up using one STG node but the respondent is connected via a different STG.

A cluster can include both host based nodes (e.g. ProsodyS) and card based nodes (e.g. ProsodyX) to support both TDM and SIP trunks. Note however that the card used for the TDM node must also provide a SIP interface as this is used for bridging calls across nodes. For this reason, it is not possible to include TDM only card based nodes (e.g. Prosody) in a cluster.

Advanced routing of calls through a specific cluster can be configured using the Python script (SelectTelephonyNode.py) in the Softdial\SP\Scripts folder. This script is used by the dialer service to select a node within a cluster, based on user settings. The following variables are available within this script at run-time:

• Telephone number
• Tenant Name
• Campaign Name
• Agent Extension
• Agent Name
• Telephony Layer ID
• Session ID
• Trunk capacity of a node
• Trunks in use in a node
• Node ID (STG VM's network name)
• Number of nailed up agents

The following are examples of possible modifications using the above variables:

1. The script by default has access to the trunk information on all nodes and clusters on Softdial CallGem™. It is therefore possible to route the calls through different nodes/ clusters, e.g. based on current trunk usage.
2. The default behaviour of the script is to select a node that is consuming the minimum number of trunks in a cluster at any one time (load balancing). But it is possible to modify the script to wait for a single node to consume x number of trunks first before moving on to a different node within the same cluster. This provides the ability to overflow calls based on pre-defined criteria.
3. The script can be configured to tie-up interviewer login to a specific node within the cluster. This could be useful in a scenario where a customer would like to tie-up say German agents to a German STG (where the German STG is part of a large cluster of STGs spread across multiple countries).
4. The script provides the ability to log the routing information in the dialer logs for later troubleshooting.

The script cannot be configured dynamically; a change in this script requires a service restart.

Please talk to Sytel before making a change to this script, as a complex script can affect the performance of the system.