SIP Server in Cluster Mode

With SIP Server in Cluster mode, you can create a highly scalable architecture in which the system's capacity can be scaled up or down with minimal configuration changes. You can add new instances of SIP Server to the SIP Cluster at any time to increase its capacity. You can also reduce the SIP Cluster size when you need to, by gracefully removing any unnecessary nodes.

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 three 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 this instance of SIP Server. Universal Routing Server (URS) and Orchestration Server (ORS) are the only clients connecting to the default port of Session Controller.
• T-Controller—maintains a subset of Agent/DN states. In Cluster mode, T-Library clients connect to the TController port instead of the default port with the exception of URS/ORS.
• 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 protocol. ICON connects to the T-Library listening port configured with the IProxy protocol.

SIP Server internal interfaces

See Configuring SIP Servers.

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 processed calls locally, on the node where those calls originally arrive. 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 allows to limit the load on URS and ORS and, as a result, improves the routing solution scalability.

To process a higher call volume, the SIP Cluster is scaled up by adding new instances of SIP Server. The SIP Cluster is designed to have all calls distributed 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 (I-Proxy) balances the call-related events across multiple instances of ICON. In the high performance environment, the cluster of ICONs may 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.

I-Proxy uses the IPport listening port to communicate with its clients.

T-Controller

T-Controller (TC) is responsible for:

• Maintaining the states of specific DNs and agents, and 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 T-Controller clients:

• TC provides a new T-Library-based smart client interface. This interface allows TC clients to monitor only those DNs, which have an ownership on this TC. This approach allows to optimize lengthy and CPU/network consuming registration process, which benefits both the server and its client. Feature Server and ICON are the examples of smart clients.
• TC still supports the regular T-Library protocol for backward compatibility to allow legacy clients to connect. It should be noted that 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.

DN Ownership

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

There are two types of DN ownership:

• TLib-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 TUnregisterAddress 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 option dn-owner-applications 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.

T-Events distribution

In the SIP Cluster architecture, all T-Library clients connect to SIP Server through its Cluster interfaces—T-Controller (TC) and Interaction Proxy (IProxy). SC generates the standard sequence of T-Events for each call it processes and distributes those events through TC and IProxy interfaces to the T-Library clients.

SIP Server logs in SIP Cluster mode

SIP Server in cluster mode runs in multi-threaded 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. 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. Log contains all call SIP messages.
512	SIPS_usw1c_1-512.20160913_173413_575.log	SVC	Session Controller	Service Checker	Manages OPTIONs messages, all OPTIONS and associated in-service/out-of-service messages here.
768	SIPS_usw1c_1-768.20160913_173413_393.log	-	Session Controller	Transport	Connection for all SIP traffic, but log does not contain much data.
1024	SIPS_usw1c_1-1024.20160913_173413_557.log	-	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 HTTP interface.