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
- T-Controller—T-Library interface for Genesys servers and ICON (to monitor agent- and DN-related T-Events?)
- Interaction Proxy—T-Library interface that distributes interactions across the clients in a pool (or across ICONs?)
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.
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. 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.