How does URs handle multi-queue routing?

[victor]

Hi, Kevin,

I don't see the reasoning behind this other than failure to address it. Looks like a limitation to me
and the faster Genesys fixes it the better.
(We are talking about inability to preserve priority across different statservers, right?  )

[Kevin S]

My apologies... I forgot to post in context... it should have read

<sarcasm>It's not a bug, it's an "Undocumented Feature"</sarcasm>

or

<poor attempt at humor>It's not a bug, it's an "Undocumented Feature"</poor attempt at humor>

But I agree - you would think that the platform would have evolved enough to be able to recognize a "global" priority of a call, regardless of the number of TServers, URSs, and Stat Servers involved...

[Mike Kamlet]

The option with 2 URS is pulse-time (assuming you use verification time).

Each URS will mark the available agent with the time when they are free and check that list every second (on the second).

Each URS will then send its own RouteCall with ReserveAgent and T-Server will sort out which call will be routed. (there are also ReserveAgent timers to determine how long to wait for all the requests).

A few caveats:

1) T-Server while performing the Reserve Agent functionality, will not take into account the agent's state.  Therefore if the agent changed state after T-Server received the Reserve Agent, but before it replied, it will still acknowledge one of the requests.
Therefore you don't want the timer to be very long.

2) In order for pulse time to work, the servers where URS is running needs to be time synch'd so that each URS will check the list "on the second"

3) The call that gets "rejected" during the Reserve Agent will simply be put back into queue at the top of the list.
Its possible that this would also cause calls to be routed "out of order"

Consider the following:

URS1                                                URS2
  Call 1 Priority 10                                Call 2 priority 9
  Call 3 Priority 8                                  Call 3 priority 5

So when the first agent becomes available URS1 sends Call 1 URS2 sends Call 2

Call 1 will be selected and call 2 will go back to be routed
If a second agent becomes available during this process, call 3 will be routed

Therefore the calls would be routed to agent as follows:
Call 1
Call 3
Call 2
Call 4

assuming agents are becoming available at the same time

Hope some of this makes sense...

Mike

[victor]

Hi, Mike,

thank you for the explanation. Makes sense.

I would just rely on AttributePriority. Pulling-time presents a problem to me, because by default it is 2 seconds, and since they are not synchronized, there is a chance that a call with a lower priority would be accepted by TServer.


Lowering that amount would increase load on URS, so it is really a balance between how fast you want to deliver the call to the agent and how much priority matters in your workplace.

[Mike Ksmlet]

We have pulse time set at 1 sec -- otherwise it really wouldn't work

We have not really noticed any impact on our URS applications -- we process anywhere between 100-200K calls/day through a set of URS

[asanti]

How did lowering pull-time from 2 seconds to 1 second helped it? 

[Mike Kamlet]

Pulse time works by checking the list of available agents every X seconds on the second based on when the URS was started.

Therefore if I have 2 URS and each check its list of available agents every 2 seconds, then its possilbe that URS 1 will check the list at 11:03:35 seconds and URS 2 checks at 11:03:37

Therefore URS 1 will always get to the agents first...

If its set to 1 seconds, the both URS will check the list at 11:03:35, 11:03:36, etc -- and Reserve agent will work fine

[victor]

I thought they fixed that problem in 7.5 where pulls are perfectly synchronized between multiple URS.

I am not very keen on reducing pull time to 1 second because I assume a very high increase in load on URS during the rush hours. Do you have some numbers on change in load when using 2 seconds and 1 seconds pulltime respectively?

Best regards,
Vic

[Mike Kamlet]

Unfortunately our capacity planning was not that advanced at the time we made the change from 2 sec to 1 sec so we don't have any data on the change.  As I recall it was still a non-event. 

The only item that has seemed to impact our URS seems to have been call volume.  In fact we've recently changed over to a much more structured template-based approach for some of the calls (which requires lots of IF type statements, more logging, subroutines) and we have not seen any impact on performance.

[Steph]

I have been working on the template that Vic designed for me some time ago. I have one strategy loaded on all of my VDNs and then it uses IF() to decide how to route the call.

A few weeks he has modified it so that it uses this GetConfigOption[] to determine on routing and I was trying to figure it out (I am worried that I have already asked him way too many question about this).

He even made it so that I don't need to load strategies even. Pretty cool!

[mark]

Ahh pulse_time.
We have noticed that the default value '2' causes some delay in routing to the agents while using verification time (all 3 of them!).

We are planning to change it to '1' soon, which should resolve one of our prod issues.

[victor]

I found pulse-time to be a bit of a drag, because making it short causes some of the calls routed first even though there are more qualified calls that should have been routed ahead of time. We have 8 URSs working together via several LDS connected to quite a few T-Server, so as you can imagine, it complicates the thing incredibly.