T-Controller role in the cluster [DRAFT]
To provide scalability on a level of DN monitoring, the cluster solution equally divides DN space among cluster nodes, where each node is responsible for maintaining state of assigned DNs. This is achieved by implementing in SIP Server an internal module: T-Library Controller (or T-Controller).
All T-Controllers are connected to each other in the cluster. All DNs in the cluster are uniformly distributed across all T-Controllers. T-Controller provides the T-Library DN-based request/event interface for SIP Server clients.
T-Controller, which owns a DN, maintains the state of this DN and an agent that is logged in on this DN. Each T-Controller has a range of DNs that it is responsible for. DNs are assigned to T-Controllers dynamically by using a hash function.
To register DNs, a client must connect to a T-Controller. It can connect to any T-Controller from the cluster. DNS resolution is used to select a particular T-Controller for DN registration.
There are two types of T-Controller clients: clients with explicit DN registration (such as, Interaction Workspace) and bulk registrants (such as, ICON and Stat Server).
For a single DN registration, a client sends a TRegisterAddress request to register a DN. The T-Controller verifies whether any T-Controller is in charge of this DN. If it is, the T-Controller proxies T-Library messages between the client and the T-Controller that is in charge of the DN.
For a bulk DN registration, a client sends a TRegisterAllKnownDNs request to register and monitor all DNs on a particular node.
Smart T-Lib clients. Functionality intended to decrease the number of proxied messages. clients are the agent desktops, which disconnect from the TC based on the EventPrivateInfo to re-connect to the TC-owner.
Bulk registrants
- definition: T-Lib clients, which have to monitor all DNs
- optimization: such clients register to all DNs with one request
- Bulk registrant protocol explained: registration, snapshot, input mask, etc
[OLD]
T-Controller clients register DNs that they control on a given T-Controller node by using the TMonitorAllKnownDNs request. If registration is successful, T-Controller responds with EventACK and updates clients with the current state of monitored DNs using EventPrivateInfo MsgID 8197 (EventClusterDNStatus). After all EventClusterDNStatus events have been sent, T-Controller sends EventPrivateInfo MsgID 8197 (EventEndOfSnapshot) indicating that snapshot transmission has ended.
SIP Server distributes events only for those DNs that are controlled by T-Controller. Events for other DN types are not reported to SIP Server clients. [Contradicts with the above statement?]
In a TMonitorAllKnownDNs request the client can set an input mask to specify events that the client wants to receive. In addition, it can specify a UserData filter to limit User Data in events to only requested keys.
The following TQueryAddress types are not supported: [Move it to the T-Library support?]
- AddressInfoNumberOfAgentsInQueue
- AddressInfoNumberOfAvailableAgentsInQueue
- AddressInfoNumberOfCallsInQueue
- AddressInfoQueueStatus
- AddressInfoQueueLoginAudit
Configuration
T-Controller listening port is configured in the SIP Server Application > Server Info.
AttributeExtensions keys
SIP Server supports the following key-value pairs in AttributeExtensions of TRegisterAllKnownDNs requests: UDataFilter and InputMask.
UdataFilter—A key-value list of User Data keys in the following format:
key-<%d> <key value>
where %d is the key’s sequential number starting from 1 and key value is the value of the key in a string format.
If UdataFilter is missing, no filter is used. If the UdataFilter list is empty, the entire User Data is filtered out.
InputMask— Specifies which events T-Controller distributes to a client. The Input Mask value is the same as in AttributeInputMask of TSetInputMask.