SIP Server in Cluster Mode

With SIP Server in Cluster mode, you can create a highly flexible architecture designed to utilize resources evenly by distributing calls and agent sessions across all available SIP Servers. Once configured, new SIP Servers added to the cluster start accepting calls and agent sessions automatically.

SIP Server in Cluster mode is designed to support high call volumes over a large number of SIP phones and logged-in agents.

When working in Cluster mode, SIP Server uses the following internal modules to provide SIP Cluster functionality:

Session Controller: call processing engine that manages SIP signalling and T-Library protocol for calls, processed locally by SIP Server. Universal Routing Server (URS) and Orchestration Server (ORS) are the only clients that connect to the default port of Session Controller.
Interaction Proxy: T-Library interface that distributes events for local calls grouped by a call interaction. Interaction Concentrator server (ICON) is the only client supporting the Interaction Proxy (IProxy) protocol.
T-Controller: T-Library interface that maintains a subset of agent/DN states and interconnection to other T-Controllers in the cluster. Supports the standard T-Library protocol and the smart client T-Library protocol extension.
Smart Proxy: T-Library interface for event monitoring clients (Stat Server). This module proxies communication between clients and all T-Controllers to increase SIP Cluster flexibility.

Client connections in SIP Cluster

T-Library clients can be grouped based on their connections in SIP Cluster, as follows:

Smart clients—ICON, SIP Feature Server, custom smart clients—support the smart client T-Library protocol extension. Smart clients connect to the T-Controller port (TCport) of a Cluster node and receive events on DNs that are owned by this node.
Agent desktop clients—Web Services and Applications (GWS), GPlus Adapters—support the standard T-Library protocol and send agent-related requests. Agent desktop clients connect to the T-Controller port (TCport) and receive events on registered DNs.
Legacy DN monitoring clients—Stat Server—don't support the T-Controller's smart client protocol extension and don't send agent-related requests. DN monitoring clients connect to the Smart Proxy port (SmartProxy).
Local node routing clients—URS, ORS—monitor and route calls processed by a local SIP Cluster node. Local node routing clients connect to the default port.

The following diagram presents component connectivity of a SIP Cluster Node with the Smart Proxy module enabled.

Diagram legend:

SIP: SBC load balances the incoming SIP traffic to SIP Proxies.
SIP: SIP Server communicates with Genesys Voice Platform (GVP) through SIP Proxy.
RTP: Media connection between the SBC and GVP.
SIP: SIP Server uses SIP Proxies in active-active mode.
TLib: ORS is connected to the default port of SIP Server to monitor Routing Points.
TLib: URS is connected to the default port of SIP Server to monitor Routing Points.
HTTP: SIP Server sends queries to an external Dial Plan implemented in SIP Feature Server.
TLib: ICON connects to the Interaction Proxy port (IPport) to receive call-related T-Library and call monitoring events.
TLib: ICON connects to the T-Controller port (TCport) to receive agent-related events.
TLib: Web Services and Applications (GWS) connects to the TCport to register to agent DNs as requested by Workspace Web Edition (WWE) desktops.
TLib: Stat Server connects to the SmartProxy port to register to all Extension and Routing Points DNs.
TLib: SIP Feature Server connects to the T-Controller port (TCport).

SIP Server Internal Modules

Session Controller

Session Controller (SC) is responsible for processing the call. SC operation is comparable to how SIP Server works in standalone mode. SC sends call-related events to its clients—URS and ORS—for the DNs that are involved in locally processed calls, on the node where those calls were received. URS and ORS are connected directly to the default SC port. URS and ORS are registered on the Routing Point DNs and receive information only about the calls processed on this SIP Server. This approach limits the load on URS and ORS and, as a result, improves the routing solution felxibility .

To process a higher call volume, you can change up the SIP Cluster by adding new instances of SIP Server. The SIP Cluster is designed to distribute all calls across all existing SC's. Each call is processed by one SC. All manipulations required for this call, such as transfers and conferences, are performed on this SC. A call is never transferred from one SC in the SIP Cluster to another. The SIP Cluster architecture ensures that the same SC processes all related calls, such as main and consultation calls initiated from the same DN.

Interaction Proxy

Interaction Proxy (IProxy) balances call-related events across multiple instances of ICON. In the high performance environment, the cluster of ICONs can be connected to one SIP Cluster node and calls processed on this node will be evenly distributed across all instances of ICON. All call-monitoring events and call-related T-Events generated for one call are directed to the same instance of ICON.

IProxy uses the IPport listening port to communicate with its clients.

T-Controller

T-Controller (TC) is responsible for the following actions:

Maintaining the states of specific DNs and agents; generating events for these DNs and agents to the clients connected to the TCport and also to the other TCs in the SIP Cluster.
Proxying T-Events received from other TCs in the SIP Cluster to the local clients connected to the TCport.
Proxying call-related T-Events from a local SC to clients connected to the TCport and also to the other TCs in the SIP Cluster.

There are two types of T-Controller clients:

TC provides a T-Library-based smart client interface. This interface allows TC clients to monitor only those DNs, that have an ownership on this TC. This approach optimizes lengthy and CPU/network-consuming registration process, which benefits both the server and its client. SIP Feature Server and ICON are the examples of smart clients.
TC also supports the regular T-Library protocol for backward compatibility to allow legacy clients to connect. Legacy clients connected to TC and registering all SIP Cluster DNs affect the SIP Cluster capacity, which degrades with the increasing number of legacy T-Library clients. For Stat Server applications, Genesys recommends enabling the Smart Proxy module.

T-Controller DN Ownership

All Extension DNs (and associated agents) are distributed across available SIP Cluster nodes for state maintenance. If SIP Cluster controls the state of a certain Extension DN, it means that SIP Cluster owns all activities associated with the DN, including its calls, a logged-in agent, and supervision subscriptions.

There are two types of DN ownership:

T-Library-based ownership (DN contact is not set to "*") is for the PSTN/remote agents. For these DNs, ownership is assigned to the first SIP Server in the data center that receives a TRegisterAddress request from a client privileged to establish DN ownership. Ownership is released when the TUnregisterAddress request is received from the client for the DN or the client disconnects. The names of client applications that are privileged to establish DN ownership, are defined by the DN-level dn-owner-applications option , which is configured on the VoIP Service DN with service-type=sip-cluster-nodes.
SIP-based ownership (the DN contact is set to "*") is for SIP registered phones. For these DNs, ownership is assigned to the first SIP Server in the data center that receives a SIP REGISTER request from SIP Proxy. Ownership is released after SIP REGISTER expires.

Smart Proxy

Introduced in SIP Server version 8.1.103.24, Smart Proxy offers the T-Library-based interface with a dedicated listening port to legacy T-Library clients, such as Stat Server, to monitor a large number of DNs regardless of the DN ownership by a Cluster Node. This greatly improves SIP Cluster flexibility. .

Smart Proxy connects as a smart (bulk-registrar) client to all SIP Cluster T-Controllers, enabling T-Controller optimization and reducing inter T-Controller message exchange. By opening a single connection to the Smart Proxy, T-Library monitoring clients receive information about all DNs.

Smart Proxy does not accept agent and supervisor requests, and smart T-Library connections. The agent desktop and bulk registrants must be connected to the T-Controller port.

The Smart Proxy module is enabled on the SIP Cluster Node by configuring the SmartProxy port in the SIP Server application and connecting Stat Server applications to that SmartProxy port instead of the T-Controller port.

Important

Genesys recommends enabling Smart Proxy for all new SIP Cluster deployments. For existing SIP Cluster deployments, Smart Proxy can be enabled if the T-Controller peak CPU usage reaches 75%.

Enabling Smart Proxy

To enable Smart Proxy functionality in the existing SIP Cluster environment, perform the following steps in all SIP Cluster Nodes. Each step must be completed in all SIP Cluster Nodes in all data centers, before continuing to the next step. Consider performing these steps during a maintenance window.

Upgrade all SIP Server applications to version 8.1.103.24 or later.
Configure the SmartProxy port in all SIP Server applications.
Restart SIP Server applications to enable Smart Proxy by using the rolling restart procedure, without service interruption:
1. Restart the backup application.
2. Wait for primary/backup synchronization to be completed.
3. Do a switchover.
4. Restart the new backup application.
Reconfigure Stat Server applications to connect to the SmartProxy port instead of the T-Controller port (TCport).
Restart Stat Server applications.
Set the smart-proxy-enabled option to true in the SIP Cluster Node DN. This triggers T-Controllers to work in optimized mode.

Disabling Smart Proxy

To disable Smart Proxy functionality:

Set the smart-proxy-enabled option to false in the SIP Cluster Node DN. This triggers T-Controllers to work in non-optimized mode.
Reconfigure Stat Server applications to connect to the T-Controller port (TCport) instead of the SmartProxy port.
Restart Stat Server applications.
Remove the SmartProxy port from SIP Server applications.
Restart SIP Server applications.

SIP Server logs in SIP Cluster mode

SIP Server in Cluster mode runs in multithreaded mode. The following prefixes represent the different subsystems in the SIP Server:

Thread ID	Example log name	Log tag	Subsystem	Thread name	Thread purpose
-	SIPS_usw1c_1.20160913_173417_999.log	CTI	Session Controller	Main thread	T-Library messages for the calls processed on a local node. It does not contain T-Library events related to an agent state.
001	SIPS_usw1c_1-001.20160913_173413_638.log	SIP	Session Controller	Call Manager	SIP processing. The log contains all call-related SIP messages.
512	SIPS_usw1c_1-512.20160913_173413_575.log	SVC	Session Controller	Service Checker	Manages OPTIONS messages and associated in-service/out-of-service messages.
768	SIPS_usw1c_1-768.20160913_173413_393.log	-	Session Controller	Transport	Connection for all SIP traffic, but the log does not contain much data.
1024	SIPS_usw1c_1-1024.20160913_173413_557.log	IPR	Interaction Proxy	Interaction Proxy	Interaction Proxy subsystem. Contains call-based T-Library messages for ICON.
1280	SIPS_usw1c_1-1280.20160913_173413_703.log	TCO	T-Controller	T-Controller	T-Controller subsystem. Contains call and agent-related T-Library messages for all clients.
1536	SIPS_usw1c_1-1536.20160913_173413_822.log	-	Session Controller	System Monitor	Shows collected statistics available through the HTTP interface.
1792	SIPS_usw1c_1-1792.20160923_172451_126.log	SPR	Smart Proxy	Smart Proxy	Smart Proxy subsystem. Contains all T-Library messages for Stat Server.

See Configuring SIP Servers.

Contents