SIP Server

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 cluster at any time to increase its capacity. You can also reduce the 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 T-Library desktops (is it still true?)AF:logged-in Agents. SIP Server in cluster mode is also able to support an increased number of Genesys reporting and routing components, in which large volumes of data are produced.AF:Statement is not clear and confusing, imo. I'd remove it

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

• Session Controller—call processing engine, it manages SIP signalling and tlibrary protocol for calls, processed locally by this instance of SIP Server. URS and 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 'default' port, except URS/ORS.
• Interaction Proxy—T-Library interface that distributes events for local calls, grouped by call interaction. ICON is the only client supporting Interaction Proxy protocol, it connects to the T-Library listening port configured with 'IProxy' protocol.

File:New-diagram.PNG

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 they originally arrive. URS and ORS are connected directly to the default SC port. [AF:ADD]To process a higher call volume, the cluster is scaled up by adding new instances of SIP Server. The 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 cluster to another. The cluster architecture ensures that the same SC processes all related calls, such as main and consultation calls initiated from the same DN.

[AF:I added T-Event distribution chapter, below]

T-Events distribution

SIP Server in cluster mode provides all functionality that is available in a stand-alone SIP Server in terms of call processing and call representation through the T-Library interface. In a cluster architecture, all T-Library clients connect to SIP Server through its cluster interfaces—T-Controller (TC) and Interaction Proxy (IProxy). The only exception to this rule is Universal Routing Server (URS) and Orchestration Server (ORS), which connects directly to the default SC listening port. 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.

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 cluster.

There are two types T-Controller clients:

• Stat Server, LDS, and GWS use a regular TLib API sequence (RequestRegisterClient) to register for any DN in the cluster. Stat Server and LDS register for all DNs. GWS only registers for DNs for agents that are currently engaged in a session.
• Bulk registrants, such as ICON, send a special TPrivateService request to register for the DNs that are owned by this particular T-Controller.

DN Ownership

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 region that receives a TRegisterAddress request[AF:ADD]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 (DN contact is set to "*") is for SIP registered phones. For these DNs, ownership is assigned to the first SIP Server in the region that receives a SIP REGISTER request from SIP Proxy. Ownership is dropped after SIP REGISTER expires.

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 are directed to the same instance of ICON.

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