Example of multisite BSR with slow networks

Last Updated : Feb 01, 2013 |
Prolog information
Metadata
Keywords:
Network response times are not an issue for most users. This example is intended for those users, if any, who experience such a problem. This example uses the same VDN, application plan, and a four-server network that is described in the example of multisite BSR with limited trunking. The vector in the example minimized interflows by using a goto step that skips the remote consider series if a local resource has an available agent. The design is especially useful if network response times are slow. Calls are always queued locally once before being queued at remote locations.
Both status polls and interflows are conditional. The call can wait in the queue for a local resource while BSR looks for a better split or skill at remote locations.
The example also shows the function of the check best command and the wait-improved conditional.
The following example illustrates the primary vector for the application, vector 100. The first consider series in the primary vector tests two local splits and queues the call to the best split. If the EWT for the best split is less than 30 seconds, step 5 jumps to the loop in step 11 and the second consider series is not executed. If the EWT for the best split is more than 30 seconds, steps 6 through 9 test 4 remote locations. If the best remote location reduces the EWT of a call by more than 30 seconds as compared to its EWT in the best local queue, step 10 interflows the call to the location.
Caution:
Queue calls once before using the wait-improved conditional in a vector step. If calls are not already queued when the step with the wait-improved conditional executes, the server reads the EWT of the call as infinite. This can result in a vector that interflows all calls, even if interflowing not the intended function.

Multisite BSR with EWT

1. wait time 0 secs hearing ringback
2. consider skill   1  pri m   adjust-by  0
3. consider skill   2  pri m   adjust-by 20
4. queue-to-best
5. goto step 11 if expected-wait for call <= 30
6. consider location 1         adjust-by 30
7. consider location 2         adjust-by 30
8. consider location 3         adjust-by 50
9. consider location 4         adjust-by 50
10. check best if wait-improved > 30
11. announcement 1001
12. wait time 60 secs hearing music
13. goto step 11 if unconditionally
A consider series can end with either a queue-to best or a check best step. The check best command lets you set conditions that must be met before a call is queued to the best resource. In this example, step 10 in the primary vector is check best if wait-improved > 30. In other words, step 10 interflows the call to the best location found by the consider series only if the EWT for the location is more than 30 seconds better than the EWT of the call in the local queue.
You can use up to 3 consider series in one vector. You can write more than 3 consider series in a vector, but there is no benefit in doing so. The server only allows you to queue a call simultaneously to 3 different local resources. Since each consider series ends by queuing a call, if no agents are available, using more than 3 series in a vector does not place the calls in additional local queues. If the call interflows to another Communication Manager, the call is removed from vector processing and any queues the call was in on the origin server.
You can combine singlesite and multisite consider series, as this example shows. Note that user adjustments are entered for local skill 2 as well as for locations 3 and 4. These indicate your preferences regarding both local and remote resources. In this example, say that step 2 queues the call to skill 1, which has an EWT of 65 seconds, before the second consider series is executed.