Agent Reservation Conflicts

[New Page]

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 a SIP Cluster system, 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.

Important

Agent reservation conflicts are normal in a SIP Cluster environment where multiple nodes route different calls using the same strategy and target the same group of agents. Conflicts can increase customer wait time as another reservation attempt is required if initial request is rejected. In Clusters, conflicts cannot be avoided completely due to the distributive nature of the system. But they can be minimized as discussed in the next section.

Warning

It is important to differentiate between the commonly prevalent problem of an understaffed call center and agent reservation conflicts. Both are different scenarios. Agent reservation conflicts come into play only when there are multiple available agents and calls are competing for those agents. But the scenario where there are not enough agents in a call center does not have anything to do with reservation conflicts.

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:

Routing to Unavailable DNs During Network Outages

• 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	Better isoloation and modularity (URS maintenance on one node does not affect other nodes). Better reliability. Better suited for automated deployment.	Fewer agent reservation conflicts (number of conflicts increases with addition of new DCs or new URS instances in a DC). Fewer components to deploy.
Cons	Number of agent reservation conflicts grows with the number of nodes.	Less reliable than node-based routing. In case of multiple URS instances per DC manual pairing of URS and SIP Cluster nodes is required.