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 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.
• 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.
• 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.
• Smart Proxy—T-Library proxy between legacy T-Library event monitoring clients (Stat Server) and all T-Controllers to support SIP Cluster scalability.

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

SIP Server internal interfaces

Diagram legend:

1. SIP: SBC load balance the SIP traffic to SIP Proxies(.?) SBC uses the SRV FQDN to reach SIP Proxies.
2. SIP: SIP Server talks to GVP through SIP Proxy.
3. RTP: Media connection between SBC and GVP.
4. SIP: SIP Server uses SIP Proxies in active-active mode.
5. TLib: ORS is connected to the default port of SIP Server to monitor Routing Points and Virtual Queues. Extensions are not available.
6. TLib: URS is connected to the default port of SIP Server to monitor Routing Points and Virtual Queues. Extensions are not available.
7. HTTP: SIP Server sends queries to external Dial Plan implemented on Feature Server.
8. TLib: ICON in cluster mode connects to the Interaction Proxy port (IPport) to receive call-related T-Library and call monitoring events.
9. TLib: ICON in cluster mode connects to T-Controller port (TCport) to receive agent-related events
10. TLib: GWS connects to TCport to register to all extensions DNs as requested by WWE desktops
11. TLib: Stat Server connects to SPport to register to all Extension and Routing Points DNs. Activities from all cluster nodes are reported.
12. TLib: Feature Server connects to the T-Controller port (TCport).
13. TLib: OCS connects to the T-Controller port (TCport).

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.

Smart Proxy

[FDS: https://intranet.genesys.com/pages/viewpage.action?spaceKey=RDSIPS&title=Smart+Proxy+module+of+SIP+Cluster]

Introduced in SIP Server version 8.1.103.xx, Smart Proxy offers a 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 scalability.

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.

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. 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. Log contains all call 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 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 the HTTP interface.

See Configuring SIP Servers.