Contents
Agent Reservation in SIP Cluster
[In progress]
Agent Reservation is a very important concept in SIP Cluster. The Agent Reservation flow is illustrated with the following sample diagram:
In the above diagram, Interaction Server is added to handle multimedia interactions for agents. Interaction Server is connected to all routing Stat Servers and reports agent states to all routing Stat Servers in the environment. All routing Stat Servers are aware of the activities of the multimedia agents. Interaction Server is connected to all URS instances in the SIP Cluster and this allows Interaction Server to load balance the routing requests across all available URS instances.
Voice calls arriving to the SIP Cluster Node are processed by routing components installed on this node. Agents handling voice calls are logged into the SIP Cluster and their locations are reported to all routing Stat Servers.
A pair of VQ SIP Server instances runs in regular non-cluster mode and is used for agent reservation purposes, as follows:
- If the agent location is specified by the site(x) function, then the VQ SIP Server associated with that particular agent is used.
- If the agent location is unknown, then the VQ SIP Server is selected based on priority, which is specified in the agent_reservation option, the [__ROUTER__] section of the VQ SIP Server.
Reservation Based on Agent Location
The following sample diagram illustrates reservation based on the agent location:
Agents handling voice calls have DN ownership assigned in the SIP Cluster Node. DN ownership defines the agent location. SIP Server reports the agent location in EventAgentReady in the site key-value pair of AttributeReason. The value of the site key is taken from the application-level geo-location option of SIP Server. URS selects the VQ SIP Server to send the reservation request based on the geo-location option. In the diagram, the TReserveAgent request for Agent2 is sent to SIPS_VQ_2.
Agents handling multimedia interactions don't have DN ownership assigned. Interaction Server doesn’t report the agent location. URS selects the VQ SIP Server for reservation based on priority, specified in the agent_reservation option, the [__ROUTER__] section. In the diagram, the reservation priority of SIPS_VQ_1 is 4, the higher digit the higher priority. So all reservation requests are sent to SIPS_VQ_1. If SIPS_VQ_1 is unavailable, reservation requests are sent to SIPS_VQ_2.
When URS is trying to select the VQ SIP Server for a particular agent, it takes into account the site key-value that is set to the geo-location of teh VQ SIP Server. In the diagram:
- For Agent 1, all requests for agent reservation are sent to SIPS_VQ_1, which has geo-location set to DC1.
- For Agent 2, all requests for agent reservation are sent to SIPS_VQ_2, which has geo-location set to DC2.
Agent Reservation Conflicts
Agent Reservation conflicts occur when there are multiple URS instances trying to route a call to the same agent. The distributive nature of the SIP Cluster system might cause reservation conflicts often, compared to systems with one URS instance targeting one agent.
In the SIP Cluster, inbound load is distributed evenly across all SIP Cluster Nodes. At some point, when all nodes use the same switch and serve the same set of routing points, all URS instances might follow the same logic written in a particular strategy and use the same view of SIP Cluster. This view is provided by the routing Stat Server. The T-Controller layer also has the same view. In effect, a global view of the SIP Cluster is distributed to all routing Stat Servers and as a result, all those URS instances can try to target the same agent for different calls.
A possibility of reservation conflicts that might occur is illustrated with the sample architecture diagram given below:
Consider that the geo-location and agent_reservation properties have been configured as follows for the above sample scenario:
| SIPS_VQ_1 | Options/[Tserver]: geo-location = DC1 Options/[__ROUTER__]: agent_reservation=4 |
| SIPS_VQ_2 | Options/[Tserver]: geo-location = DC2 Options/[__ROUTER__]: agent_reservation=3 |
| SIPS1, SIPS2 | Options/[Tserver]: geo-location = DC1 |
| SIPS3, SIPS4 | Options/[Tserver]: geo-location = DC2 |
In the above diagram, there is a call on SIP Server 1 and another on SIP Server 3. The calls are sent to URS 1 and URS 3. The routing Stat Server provides the same set of DNs (DN1 and DN2) in both cases. Both URS instances send a TReserveAgent to Agent 2 (DN2).
Reservation Call Flow
- Calls to Nodes 1 and 3 are processed by their independent routing solutions in parallel.
- Routing Stat Servers on both nodes suggest the same set of target DNs.
- URS instances on both nodes decide to route their respective calls to DN2.
- Both URS instances select SIPS_VQ_2 for reservation, based on location of Agent 2.
- Request from Node 3 is granted and request from Node 1 is rejected.
- Node 1 makes another reservation attempt to DN1, which is granted.
Centralized Routing for Reducing Conflicts
Switching to Centralized Routing reduces agent reservation conflicts. Consider the following sample architecture diagram:
The difference between the previous diagrams and the above sample is that, there is a centralized URS HA pair per DC. There is no separate URS instance serving each node. Instead, there is one URS serving the whole DC. The fewer instances of URS you use, the lesser the number of reservation conflicts as you have less players competing for available agents.
URS is connected to the default port processing local calls from SIP Server 1 and SIP Server 2. URS is also connected to the Stat Server and the Stat Server is connected through the T-Controller layer. A global view of all agents in the SIP Cluster is provided and so all DNs are still available for URS to route to. It is just that fewer instances of URS are being used.
- Reducing the number of competing URS instances automatically decreases the number of agent reservation conflicts.
- In the above sample architecture diagram, one URS HA pair is used to route all calls in a DC.
- This URS pair is connected to one of the routing Stat Servers.
Problems with Centralized Routing
Problems might occur in a centralized routing scenario when inter-node connection is lost. Consider the following the sample diagram:
- If inter-node connection is lost, the two SIP Cluster nodes present different views on DN availability to its clients.
- URS is connected to only one Stat Server.
- URS uses DN view of Stat Server 1 to route call on node 2 and as a result can route to DN in OOS state, which leads to a failed routing attempt.
URS HA Pair Becomes a Central Point of Failure
- Solution with dedicated URS HA pair per SIP Cluster node has higher reliability.
One URS HA per DC can Become a Performance Bottleneck
- Multiple URS HA pairs can be deployed and configured to serve selected groups of nodes.
- Automation of a new node deployment becomes very complex in this case because selection of URS is not trivial.
Node-Based Routing vs. Centralized Routing
|
Node-Based Routing |
Centralized Routing | |
|
Pros |
|
|
|
Cons |
|
|
Location-Based Routing
Location-based routing is another way to effectively minimize Agent Reservation conflicts. As discussed in the previous sections, URS has the ability to select a reservation server based on the agent location using the site key-value pair of AttributeReason in the EventAgentReady event.
Consider a sample scenario where the EventReadyAgent and EventQueued/EventRouteRequest'events have the following values:
|
Location of a ready agent |
Location of a call |
|
EventAgentReady |
EventQueued/EventRouteRequest |
In the above sample, the value of site is populated as uswest. At the same time, when a call arrives at the SIP Cluster node, in the EventQueued/EventRouteRequest event in the AttributeExtensions, there is another key-value pair, called geo-location. The value of geo-location is the same as that of site. URS can process and match those two values. You can enforce this by creating a skill expression using the sitex() function. For example, the routing strategy in Composer can use a skill expression like the following to route the call to only the agents logged-in to local region:
sitex(GEO_LOCATION) & English > 0
This helps reduce the number of agent reservation conflicts. geo_location is passed as a parameter to the sitex function. In this case, when the above approach is used in a SIP Cluster environment, the reservation requests for voice agents are load balanced across data centers and the VQ SIP Server's reservation requests load is reduced.
Composer supports the sitex() function. Workflows in Composer provide access to extension data (xdata) to read the geo-location. The Target block accepts a skill expression that can include the sitex() function.