Genesys CTI User Forum

Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: URSMan on July 17, 2007, 02:04:28 AM

Title: How does URs handle multi-queue routing?
Post by: URSMan on July 17, 2007, 02:04:28 AM
Hello,

I would like to ask some help with answering the following question - how does URS decide which call to route to an agent when more than one queue is targeting it?

For example, I have three queues, A, B, C all targeting the same skill. There is one agent that has all these three skills and this is the only one agent current available. You have 100 calls in queue A, 5 calls in queue B, 1 call in queue C. How does URS handle the calls? Does it do it in a round-robin fashion, where it would send one call from A then one call from B and then one call from C?

I read somewhere that priority assigned to a call is local to a queue, therefore, if call A has priority 1000 in queue A and another call B has priority 1 in queue B, it does not mean that call A will always be routed before call B. Can you  please confirm that for me?

[move]URSMan rulez! ;D[/move]
Title: Re: How does URs handle multi-queue routing?
Post by: René on July 17, 2007, 06:30:00 AM
Hello URSMan,

The interactions are routed based on their global priority which is set using the function "Priority". There is another function related to interaction's priority called SetVQPriority but that function sets priority of an interaction in connection to particular virtual queue (VQ) only.

I would suggest you to look at "Genesys Universal Routing 7.2 Deployment Guide". There is a chapter named "Business-Priority Routing" where you can find more information related to this topic.

René

PS. If you are on URS 6.5 then the global priority doesn't work as expected. It is fixed in release 7.x.
Title: Re: How does URs handle multi-queue routing?
Post by: URSMan on July 18, 2007, 12:25:46 AM
Good afternoon, Rene, and thank-you for your reply!
What about calls that do not have Priority assigned to them? Does URS route them in a round-robin fashion?
Title: Re: How does URs handle multi-queue routing?
Post by: mark on July 18, 2007, 07:30:06 AM
Different skill levels and priority levels can cause calls to route differently to expected. Always worth running a set of tests just to confirm to yourself what is going on.
Then there is any service factor rules that may be in place that need to be considered.

Page 35 in the URS Deployment Guide (mentioned by René) has a small piece on Priority Tuning that would be worth a quick read, along with the Business Process Routing sections.

Mark
Title: Re: How does URs handle multi-queue routing?
Post by: René on July 18, 2007, 08:39:22 AM
As I know every interaction has its priority set to default value 10 points at the beginning. But I don't know how URS handle these - I would bit it's kind of random selection. I definitely recommend you to read the Business Process Routing section as described functionality is targeted to solve your needs (multi VQs - one target).

René
Title: Re: How does URs handle multi-queue routing?
Post by: victor on July 18, 2007, 10:17:05 AM
I checked up on URSMan post, and you know, there is definitely something fishy about Priority routing with URS 7.1.xxx . I had two queues, both targeting the same agent, and I have added Increment[1] before queueing the call.
After waiting for a minute and then placing a call to a second queue, I would set agent to ready and you know, in some instances, URS would connect call #2 (priority=0) to operator even though there is call (priority=1) still in the other queue targeting the same agent.

tagret-order is set to random, so I wonder what this could be...



Title: Re: How does URs handle multi-queue routing?
Post by: Mike Kamlet on July 18, 2007, 07:43:41 PM
Other considerations:

1) Are you using multiple URS with LDS??
    If so there are other considerations related to reserve agent, pulse-time, etc -- we've run into issues with this in the past

2) With a single URS, priority should work fine -- highest priority always gets routed regardless of time in queue.  In fact if you have a call without priority set and a call with priority of 1, the call with priority 1 will always route first.

Mike
Title: Re: How does URs handle multi-queue routing?
Post by: victor on July 19, 2007, 03:48:42 AM
Good morning, Mike,

I checked again and again, and if you use SelectDN() and then Suspend() commands, I do get about 3 out 14 calls when priority 0 call is routed to an agent even though priority 1 call is still targeting the same agent with only one URS 7.1.xxxx and one statserver.

I will try to up the part of the log later on today or tomorrow.

Best regards,
Vic
Title: Re: How does URs handle multi-queue routing?
Post by: victor on July 24, 2007, 04:03:39 AM
To follow up on why URS is routing priority 0 when there is priority 1 call waiting in another queue, here is a sample log:

there is Skill_A and Skill_B and operator has both of these skills.
There are two strategies, targeting skill A and skill B respectively.

Strategy is setup so that call's priority is increased every minutes by one count.

Call A - 0092017974d65052 - was in queue A for over a minute for Skill A and has priority 1
Call B -  0092017974d65053 - was in queue B for less than a minute and has priority 0

Once agent becomes ready, call B is sent to operator before call A (despite call A having a higher priority). Once agent finishes call B, call A is then routed to the same operator.

Why is it doing such a nasty thing?
[code]

18:11:58.727_M_I_ [10:06] tenant Resources GroupAgents <VAG_Skill_A_H>: statistic ##content with server StatServer <request=7, status=2> asked
    _M_I_ [17:05] VQ(101b7ed20) target (name=VAG_Skill_A_H, location=StatServer, type=GA) synchronizing

request to 65202(--) message RequestDistributeEvent
AttributeExtensions [82] 00 04 00 00..
'SIGNATURE' 'router'
'NAME' 'URS1'
'VERSION' 'Version: 7.1.001.03'
'CLUSTER' 'URS1'
AttributeUserData [698] 00 1B 00 00..
'DNIS_NUM' '20005'
'CUSTID' 'CID:'
'RRequestedSkills'(list)
'CustomerSegment' 'default'
'ServiceType' 'default'
'ServiceObjective' ''
'DEBUG_GENESYS_DESTINATION' 'Switch_Tokyo'
'Site_ext' 'Tokyo'
'Skillname' 'Skill_A'
'SKILL_CODE' '21035'
'VAR_sTarget_val' '20842_Switch_Tokyo'
'VAR_sStatServer' 'StatServer'
'SubDN' '20779_Switch_Tokyo'
'RTargetRuleSelected' ''
'RTargetTypeSelected' '100'
'RTargetObjectSelected' ''
'RTargetAgentSelected' ''
'RTargetPlaceSelected' ''
'RTenant' 'Resources'
'RStrategyName' 'jump_to_routing'
'RTargetUsed'(list) 'TargetType' '100'
                    'TargetName' ''
'RRequestedSkillCombination' ''
'ReasonToCXU' 'noANI'
'VAR_nResult' '0'
'PegTD' 1
'ScriptName' ''
'VAR_sVQ' 'VQ_Skill_A_Tokyo'
AttributeDNIS '20005'
AttributeOtherDNRole 1
AttributeOtherDN '6003'
AttributeThisDNRole 2
AttributeThisQueue 'VQ_Skill_A'
AttributeThisDN 'VQ_Skill_A'
AttributeCallID 92
AttributeConnID 0092017974d65052
AttributeCustomerID 'Resources'
AttributeReferenceID 4294967295
AttributeUserEvent EventQueued
..sent to ctisssvp:5080(fd=16)
    _M_I_0092017974d65052 [17:0e] virtual queue "VQ_Skill_A_Tokyo"(id=293), VQ 101b8b6e0: target for routing was NOT SELECTED (0 0 0 1)
18:11:59.738_I_I_0092017974d65052 [09:04] <<<<<<<<<<<<suspend interpretator(WAIT_FOR_DN), timers:11000
18:11:59.738_B_I_0092017974d65052 [07:09] start chain of treatments
received from 65202(--)ctisssvp:5080(fd=16) message EventACK
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 754024
AttributeTimeinSecs 1184749919 (18:11:59)
AttributeReferenceID 4294967295
AttributeThisDN 'VQ_Skill_A'
AttributeUserEvent RequestDistributeEvent
18:12:00.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=2, time=1184749919, mem=0,90035,1399,16,123,0)
18:12:00.746_I_I_0092017974d65052 [07:08] wait time is over
18:12:00.746_I_I_0092017974d65052 [09:05] >>>>>>>>>>>>resume interpretator(0)
    _I_I_0092017974d65052 [09:04] ASSIGN: sTarget_out(LOCAL) <- STRING: return:timeout
    _I_I_0092017974d65052 [09:04] ASSIGN: nResult(LOCAL) <- INTEGER: 0
18:12:00.746_I_I_0092017974d65052 [07:48] suspend function
18:12:00.746_I_I_0092017974d65052 [09:04] <<<<<<<<<<<<suspend interpretator(JUMPING), timers:00001
18:12:00.746_I_I_0092017974d65052 [07:49] resume function
    _I_I_0092017974d65052 [07:44] jump to strategy *0x65*main_routing
18:12:00.746_I_I_0092017974d65052 [09:05] >>>>>>>>>>>>resume interpretator(0)
    _I_I_0092017974d65052 [09:04] ASSIGN: nResult(LOCAL) <- INTEGER: 0
    _I_I_0092017974d65052 [09:04] ASSIGN: sTarget_val(LOCAL) <- STRING: return:timeout
    _I_I_0092017974d65052 [09:04] ASSIGN: sPotentialTarget(LOCAL) <- STRING: VAG_Skill_A_L@StatServer.GA
18:12:00.746_I_I_0092017974d65052 [07:48] suspend function
18:12:00.746_I_I_0092017974d65052 [09:04] <<<<<<<<<<<<suspend interpretator(JUMPING), timers:00001
18:12:00.746_I_I_0092017974d65052 [07:49] resume function
    _I_I_0092017974d65052 [07:43] call strategy *0x65*sub_queue_call
18:12:00.746_I_I_0092017974d65052 [09:06] >>>>>>>>>>>>start interpretator
    _I_I_0092017974d65052 [07:46] no error mode for this call
    _I_I_0092017974d65052 [09:04] ASSIGN: __Return(SCRIPT) <- STRING:
    _I_I_0092017974d65052 [09:04] ASSIGN: __DBReturn(SCRIPT) <- STRING:
    _I_I_0092017974d65052 [09:04] ASSIGN: __DBStrReturn(SCRIPT) <- STRING:
    _I_I_0092017974d65052 [09:04] ASSIGN: __TargetVar(SCRIPT) <- STRING:
    _I_I_0092017974d65052 [09:04] ASSIGN: nTimeout_in(LOCAL) <- INTEGER: 9999
    _I_I_0092017974d65052 [09:04] ASSIGN: sTarget_in(LOCAL) <- STRING: VAG_Skill_A_L@StatServer.GA
    _I_I_0092017974d65052 [09:04] ASSIGN: sVQ_in(LOCAL) <- STRING: VQ_Skill_A_Tokyo
18:12:00.747_I_I_0092017974d65052 [07:26] HERE IS TARGETS
TARGETS: VAG_Skill_A_L@StatServer.GA       
18:12:00.747_M_I_0092017974d65052 [13:01] current virtual queue: 101b7ef30 id=294, nVQ=1|39868980-101731c80, priority=0, time=1184749920.747
18:12:00.747_M_I_ [17:0c] VQ(101b842e0) created: type=0, tenant=Resources
==========================================
    _M_I_ [17:06] VQ(101b842e0) target 101ba4f70 added: name=VAG_Skill_A_L, location=StatServer, type=GA, state=##state, activity=unknown
18:12:00.747_M_I_ [10:06] tenant Resources GroupAgents <VAG_Skill_A_L>: statistic ##content with server StatServer <request=19, status=2> asked
    _M_I_ [17:05] VQ(101b842e0) target (name=VAG_Skill_A_L, location=StatServer, type=GA) synchronizing
18:12:00.747_M_I_ [10:06] tenant Resources Agent <1602>: statistic ##state with server StatServer <request=13, status=2> asked
    _M_I_ [17:09] VQ(101b842e0), target 101ba4f70: GroupAgents <VAG_Skill_A_L> connected to state Agent 1602
18:12:00.747_M_I_ [10:06] tenant Resources Agent <1604>: statistic ##state with server StatServer <request=15, status=2> asked
    _M_I_ [17:09] VQ(101b842e0), target 101ba4f70: GroupAgents <VAG_Skill_A_L> connected to state Agent 1604
18:12:00.747_M_I_ [10:06] tenant Resources Agent <7999998>: statistic ##state with server StatServer <request=17, status=2> asked
    _M_I_ [17:09] VQ(101b842e0), target 101ba4f70: GroupAgents <VAG_Skill_A_L> connected to state Agent 7999998

18:12:00.747_M_I_0092017974d65052 [13:02] entering virtual queue "VQ_Skill_A_Tokyo"
    _M_I_ [17:0f] VQ(101b842e0) [at all 8 0] 1 target(s), flag=a, guid: 0Resources|VQ_Skill_A_Tokyo|1|-1|1|0|""|||01StatAgentLoading|00{}[]VAG_Skill_A_L@StatServer.GA
18:12:00.747_M_I_0092017974d65052 [13:03] call (virtual queue 101b7ef30, id=294, priority 0, time 1184749920.747) waits for VQ 101b842e0 (name="VQ_Skill_A_Tokyo") now
request to 65202(--) message RequestDeletePair
AttributeReferenceID 2692
AttributeDataKey 'RTargetAgentGroup'
AttributeConnID 0092017974d65052
AttributeThisDN '20719'
..sent to ctisssvp:5080(fd=16)
request to 65202(--) message RequestAttachUserData
AttributeReferenceID 2693
AttributeUserData [119] 00 03 00 00..
'RTargetAgentGroup' 'VAG_Skill_A_L'
'RTargetAgentGroup' 'VAG_Skill_A_M'
'RTargetAgentGroup' 'VAG_Skill_A_H'
AttributeConnID 0092017974d65052
AttributeThisDN '20719'
..sent to ctisssvp:5080(fd=16)
request to 65202(--) message RequestDistributeEvent
AttributeExtensions [82] 00 04 00 00..
'SIGNATURE' 'router'
'NAME' 'URS1'
'VERSION' 'Version: 7.1.001.03'
'CLUSTER' 'URS1'
AttributeUserData [815] 00 1E 00 00..
'DNIS_NUM' '20005'
'CUSTID' 'CID:'
'RRequestedSkills'(list)
'CustomerSegment' 'default'
'ServiceType' 'default'
'ServiceObjective' ''
'DEBUG_GENESYS_DESTINATION' 'Switch_Tokyo'
'Site_ext' 'Tokyo'
'Skillname' 'Skill_A'
'SKILL_CODE' '21035'
'VAR_sTarget_val' '20842_Switch_Tokyo'
'VAR_sStatServer' 'StatServer'
'SubDN' '20779_Switch_Tokyo'
'RTargetRuleSelected' ''
'RTargetTypeSelected' '100'
'RTargetObjectSelected' ''
'RTargetAgentSelected' ''
'RTargetPlaceSelected' ''
'RTenant' 'Resources'
'RStrategyName' 'jump_to_routing'
'RTargetUsed'(list) 'TargetType' '100'
                    'TargetName' ''
'RRequestedSkillCombination' ''
'ReasonToCXU' 'noANI'
'VAR_nResult' '0'
'PegTD' 1
'ScriptName' ''
'VAR_sVQ' 'VQ_Skill_A_Tokyo'
'RTargetAgentGroup' 'VAG_Skill_A_L'
'RTargetAgentGroup' 'VAG_Skill_A_M'
'RTargetAgentGroup' 'VAG_Skill_A_H'
AttributeDNIS '20005'
AttributeOtherDNRole 1
AttributeOtherDN '6003'
AttributeThisDNRole 2
AttributeThisQueue 'VQ_Skill_A'
AttributeThisDN 'VQ_Skill_A'
AttributeCallID 92
AttributeConnID 0092017974d65052
AttributeCustomerID 'Resources'
AttributeReferenceID 4294967295
AttributeUserEvent EventAttachedDataChanged
..sent to ctisssvp:5080(fd=16)
    _M_I_0092017974d65052 [17:0e] virtual queue "VQ_Skill_A_Tokyo"(id=294), VQ 101b842e0 (1 targets): SELECT MAX by statistic StatAgentLoading(random )
    _M_I_0092017974d65052 [17:0b] VQ 101b842e0 target "VAG_Skill_A_L" (#1, 3-2 components): SELECT MAX by statistic StatAgentLoading(random)
    _M_I_0092017974d65052 [17:0b] component #1 1602: not ready
    _M_I_0092017974d65052 [17:0b] component #2 1604: logged out
    _M_I_0092017974d65052 [17:0b] component #3 7999998: logged out
    _M_I_0092017974d65052 [17:0b] VQ 101b842e0 target "VAG_Skill_A_L": component was NOT SELECTED (2 1 0)
    _M_I_0092017974d65052 [17:0e] target VAG_Skill_A_L: not ready passed
    _M_I_0092017974d65052 [17:0e] virtual queue "VQ_Skill_A_Tokyo"(id=294), VQ 101b842e0: target for routing was NOT SELECTED (0 0 0 1)
  result of SelectDN: STRING: return:timeout
    _I_I_0092017974d65052 [09:04] ASSIGN: sTarget_out(LOCAL) <- STRING: return:timeout
    _I_I_0092017974d65052 [07:27] HERE IS WAIT FOR DN (9999 sec)
18:12:00.748_B_I_0092017974d65052 [07:27] delay treatments for 0 msec
18:12:00.748_M_I_0092017974d65052 [10:1f] pulse for one call
    _T_I_0092017974d65052 [0E:19] check call routing states: state=10 delivery=0 treatment=0 held=0 reserving=0 - true
    _M_I_0092017974d65052 [17:0e] virtual queue "VQ_Skill_A_Tokyo"(id=292), VQ 101b7ed20 (1 targets): SELECT MAX by statistic StatAgentLoading(random )
    _M_I_0092017974d65052 [17:0e] target VAG_Skill_A_H: empty(0-0 components) passed
    _M_I_0092017974d65052 [17:0e] virtual queue "VQ_Skill_A_Tokyo"(id=292), VQ 101b7ed20: target for routing was NOT SELECTED (1 0 0 0)
    _M_I_0092017974d65052 [17:0e] virtual queue "VQ_Skill_A_Tokyo"(id=293), VQ 101b8b6e0 (1 targets): SELECT MAX by statistic StatAgentLoading(random )
    _M_I_0092017974d65052 [17:0b] VQ 101b8b6e0 target "VAG_Skill_A_M" (#1, 3-2 components): SELECT MAX by statistic StatAgentLoading(random)
    _M_I_0092017974d65052 [17:0b] component #1 1602: not ready
    _M_I_0092017974d65052 [17:0b] component #2 1604: logged out
    _M_I_0092017974d65052 [17:0b] component #3 7999998: logged out
    _M_I_0092017974d65052 [17:0b] VQ 101b8b6e0 target "VAG_Skill_A_M": component was NOT SELECTED (2 1 0)
    _M_I_0092017974d65052 [17:0e] target VAG_Skill_A_M: not ready passed
    _M_I_0092017974d65052 [17:0e] virtual queue "VQ_Skill_A_Tokyo"(id=293), VQ 101b8b6e0: target for routing was NOT SELECTED (0 0 0 1)
    _M_I_0092017974d65052 [17:0e] virtual queue "VQ_Skill_A_Tokyo"(id=294), VQ 101b842e0 (1 targets): SELECT MAX by statistic StatAgentLoading(random )
    _M_I_0092017974d65052 [17:0b] VQ 101b842e0 target "VAG_Skill_A_L" (#1, 3-2 components): SELECT MAX by statistic StatAgentLoading(random)
    _M_I_0092017974d65052 [17:0b] component #1 1602: not ready
    _M_I_0092017974d65052 [17:0b] component #2 1604: logged out
    _M_I_0092017974d65052 [17:0b] component #3 7999998: logged out
    _M_I_0092017974d65052 [17:0b] VQ 101b842e0 target "VAG_Skill_A_L": component was NOT SELECTED (2 1 0)
    _M_I_0092017974d65052 [17:0e] target VAG_Skill_A_L: not ready passed
    _M_I_0092017974d65052 [17:0e] virtual queue "VQ_Skill_A_Tokyo"(id=294), VQ 101b842e0: target for routing was NOT SELECTED (0 0 0 1)
18:12:00.748_I_I_0092017974d65052 [09:04] <<<<<<<<<<<<suspend interpretator(WAIT_FOR_DN), timers:11000
18:12:00.748_B_I_0092017974d65052 [07:09] start chain of treatments
received from 65202(--)ctisssvp:5080(fd=16) message EventACK
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 764420
AttributeTimeinSecs 1184749920 (18:12:00)
AttributeReferenceID 4294967295
AttributeThisDN 'VQ_Skill_A'
AttributeUserEvent RequestDistributeEvent
18:12:02.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=2, time=1184749921, mem=0,90047,1401,17,123,0)
18:12:02.186 Trc 20011 current number of targets for tenant Resources: Agents 11, Places 0, AgentGroups 6, PlaceGroups 0, ACDQueues 0, Routing Points 6
18:12:02.186 Trc 20012 current number of interactions per second - 1.00
18:12:02.186 Trc 20013 current number of entries: for longest queue 0, for all queues 0
18:12:04.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=2, time=1184749923, mem=0,90047,1401,17,123,0)
18:12:04.376_M_I_ [17:0d] VQ(101b81480) deleted
18:12:04.376_M_I_ [17:08] VQ(101b81480) target 101ba4c40 deleted: name=VAG_Skill_B_L
18:12:04.376_M_I_ [17:0d] VQ(101b811e0) deleted
18:12:04.376_M_I_ [17:08] VQ(101b811e0) target 101b812f0 deleted: name=VAG_Skill_B_M
18:12:04.376_M_I_ [17:0d] VQ(101b906c0) deleted
18:12:04.376_M_I_ [17:08] VQ(101b906c0) target 1019c53d0 deleted: name=VAG_Skill_B_H
18:12:06.016_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=2, time=1184749925, mem=0,90014,1395,14,123,0)
18:12:08.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=2, time=1184749927, mem=0,90014,1395,14,123,0)
18:12:09.776_M_I_ [17:0d] VQ(101b905b0) deleted
18:12:09.776_M_I_ [17:08] VQ(101b905b0) target 101b9dc20 deleted: name=20717_Switch_Tokyo
18:12:10.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=1, time=1184749929, mem=0,90004,1393,13,123,0)
18:12:10.756_M_I_ [17:0d] VQ(101b9a7d0) deleted
18:12:10.756_M_I_ [17:08] VQ(101b9a7d0) target 101b9de60 deleted: name=20719_Switch_Tokyo
18:12:12.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749931, mem=0,89994,1391,12,123,0)
18:12:14.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749933, mem=0,89994,1391,12,123,0)
18:12:16.016_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749935, mem=0,89994,1391,12,123,0)
18:12:18.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749937, mem=0,89994,1391,12,123,0)
18:12:20.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749939, mem=0,89994,1391,12,123,0)
18:12:22.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749941, mem=0,89994,1391,12,123,0)
18:12:24.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749943, mem=0,89994,1391,12,123,0)
18:12:26.016_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749945, mem=0,89994,1391,12,123,0)
18:12:28.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749947, mem=0,89994,1391,12,123,0)
18:12:30.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749949, mem=0,89994,1391,12,123,0)
18:12:32.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749951, mem=0,89994,1391,12,123,0)
18:12:34.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749953, mem=0,89994,1391,12,123,0)
18:12:36.016_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749955, mem=0,89994,1391,12,123,0)
18:12:38.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749957, mem=0,89994,1391,12,123,0)
18:12:40.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749959, mem=0,89994,1391,12,123,0)
18:12:42.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749961, mem=0,89994,1391,12,123,0)
18:12:44.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749963, mem=0,89994,1391,12,123,0)
18:12:46.015_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749965, mem=0,89994,1391,12,123,0)
18:12:48.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749967, mem=0,89994,1391,12,123,0)
18:12:50.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749969, mem=0,89994,1391,12,123,0)
18:12:51.617_G_I_ [01:0b] look for hanged interactions: 1 at all now
18:12:51.617_G_I_ [01:0b] there are 1 calls in progress now
_G_I_ Version: 7.1.001.03
root 1009b7830
18:12:52.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749971, mem=0,89994,1391,12,123,0)
18:12:54.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749973, mem=0,89994,1391,12,123,0)
18:12:56.016_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749975, mem=0,89994,1391,12,123,0)
18:12:58.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749977, mem=0,89994,1391,12,123,0)
18:12:58.726_M_I_0092017974d65052 [07:0d] default priority 1
18:12:58.726_M_I_0092017974d65052 [13:05] current priority for all VQ(s) increased by 1
18:12:58.726_M_I_0092017974d65052 [13:03] call (virtual queue 101b7ef30, id=294, priority 0) doesn't wait for VQ 101b842e0 (name="VQ_Skill_A_Tokyo") now
18:12:58.727_M_I_0092017974d65052 [13:03] call (virtual queue 101b7ef30, id=294, priority 1, time 1184749920.747) waits for VQ 101b842e0 (name="VQ_Skill_A_Tokyo") now
18:12:58.727_M_I_0092017974d65052 [13:03] call (virtual queue 101b809f0, id=293, priority 0) doesn't wait for VQ 101b8b6e0 (name="VQ_Skill_A_Tokyo") now
18:12:58.727_M_I_0092017974d65052 [13:03] call (virtual queue 101b809f0, id=293, priority 1, time 1184749919.737) waits for VQ 101b8b6e0 (name="VQ_Skill_A_Tokyo") now
18:12:58.727_M_I_0092017974d65052 [13:03] call (virtual queue 101ba2f40, id=292, priority 0) doesn't wait for VQ 101b7ed20 (name="VQ_Skill_A_Tokyo") now
18:12:58.727_M_I_0092017974d65052 [13:03] call (virtual queue 101ba2f40, id=292, priority 1, time 1184749918.727) waits for VQ 101b7ed20 (name="VQ_Skill_A_Tokyo") now
18:13:00.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749979, mem=0,89994,1391,12,123,0)
18:13:02.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749981, mem=0,89994,1391,12,123,0)
18:13:04.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749983, mem=0,89994,1391,12,123,0)
18:13:06.016_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749985, mem=0,89994,1391,12,123,0)
18:13:08.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749987, mem=0,89994,1391,12,123,0)
18:13:10.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749989, mem=0,89994,1391,12,123,0)
18:13:12.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749991, mem=0,89994,1391,12,123,0)
18:13:14.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749993, mem=0,89994,1391,12,123,0)
18:13:16.015_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749995, mem=0,89994,1391,12,123,0)
18:13:18.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749997, mem=0,89994,1391,12,123,0)
18:13:20.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184749999, mem=0,89994,1391,12,123,0)
18:13:22.006_M_I_ [10:1d] PULSE (calls: 1(1)=1+0-0, targets=0, time=1184750001, mem=0,89994,1391,12,123,0)
18:13:24.006_M_I_ [10:1d] PULSE (calls: 2(2)=1+4-3, targets=2, time=1184750003, mem=0,90077,1396,16,124,0)
18:13:24.376_B_I_0092017974d65053 [14:apply_treatment_postproc] treatment timer is activated in APPLIED state

18:13:24.377_M_I_ [10:06] tenant Resources Agent <1704>: statistic ##state with server StatServer_Oak <request=3, status=2> asked
    _M_I_ [17:09] VQ(101b90640), target 101b90750: GroupAgents <VAG_Skill_B_H> connected to state Agent 1704

request to 65202(--) message RequestDistributeEvent
AttributeExtensions [82] 00 04 00 00..
'SIGNATURE' 'router'
'NAME' 'URS1'
'VERSION' 'Version: 7.1.001.03'
'CLUSTER' 'URS1'
AttributeUserData [686] 00 1B 00 00..
'DNIS_NUM' '20003'
'CUSTID' 'CID:'
'RRequestedSkills'(list)
'CustomerSegment' 'default'
'ServiceType' 'default'
'ServiceObjective' ''
'DEBUG_GENESYS_DESTINATION' 'Switch_Tokyo'
'Site_ext' 'Tokyo'
'Skillname' 'Skill_B'
'SKILL_CODE' '21030'
'VAR_sTarget_val' '20841_Switch_Tokyo'
'VAR_sStatServer' 'StatServer'
'SubDN' '20777_Switch_Tokyo'
'RTargetRuleSelected' ''
'RTargetTypeSelected' '100'
'RTargetObjectSelected' ''
'RTargetAgentSelected' ''
'RTargetPlaceSelected' ''
'RTenant' 'Resources'
'RStrategyName' 'jump_to_routing'
'RTargetUsed'(list) 'TargetType' '100'
                    'TargetName' ''
'RRequestedSkillCombination' ''
'ReasonToCXU' 'noANI'
'VAR_nResult' '0'
'PegTD' 1
'ScriptName' ''
'VAR_sVQ' 'VQ_Skill_B_Tokyo'
AttributeDNIS '20003'
AttributeOtherDNRole 1
AttributeOtherDN '6001'
AttributeThisDNRole 2
AttributeThisQueue 'VQ_Skill_B'
AttributeThisDN 'VQ_Skill_B'
AttributeCallID 93
AttributeConnID 0092017974d65053
AttributeCustomerID 'Resources'
AttributeReferenceID 4294967295
AttributeUserEvent EventQueued
..sent to ctisssvp:5080(fd=16)
    _M_I_0092017974d65053 [17:0e] virtual queue "VQ_Skill_B_Tokyo"(id=298), VQ 101b81270: target for routing was NOT SELECTED (0 1 0 0)
18:13:25.388_I_I_0092017974d65053 [09:04] <<<<<<<<<<<<suspend interpretator(WAIT_FOR_DN), timers:11000
18:13:25.388_B_I_0092017974d65053 [07:09] start chain of treatments
received from 65202(--)ctisssvp:5080(fd=16) message EventACK
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 404057
AttributeTimeinSecs 1184750005 (18:13:25)
AttributeReferenceID 4294967295
AttributeThisDN 'VQ_Skill_B'
AttributeUserEvent RequestDistributeEvent
18:13:26.016_M_I_ [10:1d] PULSE (calls: 2(2)=2+0-0, targets=2, time=1184750005, mem=0,90105,1400,18,124,0)
18:13:26.396_I_I_0092017974d65053 [07:08] wait time is over
18:13:26.396_I_I_0092017974d65053 [09:05] >>>>>>>>>>>>resume interpretator(0)
    _I_I_0092017974d65053 [09:04] ASSIGN: sTarget_out(LOCAL) <- STRING: return:timeout
    _I_I_0092017974d65053 [09:04] ASSIGN: nResult(LOCAL) <- INTEGER: 0
18:13:26.396_I_I_0092017974d65053 [07:48] suspend function
18:13:26.396_I_I_0092017974d65053 [09:04] <<<<<<<<<<<<suspend interpretator(JUMPING), timers:00001
18:13:26.396_I_I_0092017974d65053 [07:49] resume function
    _I_I_0092017974d65053 [07:44] jump to strategy *0x65*main_routing
18:13:26.396_I_I_0092017974d65053 [09:05] >>>>>>>>>>>>resume interpretator(0)
    _I_I_0092017974d65053 [09:04] ASSIGN: nResult(LOCAL) <- INTEGER: 0
    _I_I_0092017974d65053 [09:04] ASSIGN: sTarget_val(LOCAL) <- STRING: return:timeout
    _I_I_0092017974d65053 [09:04] ASSIGN: sPotentialTarget(LOCAL) <- STRING: VAG_Skill_B_L@StatServer_Oak.GA
18:13:26.396_I_I_0092017974d65053 [07:48] suspend function
18:13:26.396_I_I_0092017974d65053 [09:04] <<<<<<<<<<<<suspend interpretator(JUMPING), timers:00001
18:13:26.396_I_I_0092017974d65053 [07:49] resume function
    _I_I_0092017974d65053 [07:43] call strategy *0x65*sub_queue_call
18:13:26.396_I_I_0092017974d65053 [09:06] >>>>>>>>>>>>start interpretator
    _I_I_0092017974d65053 [07:46] no error mode for this call
    _I_I_0092017974d65053 [09:04] ASSIGN: __Return(SCRIPT) <- STRING:
    _I_I_0092017974d65053 [09:04] ASSIGN: __DBReturn(SCRIPT) <- STRING:
    _I_I_0092017974d65053 [09:04] ASSIGN: __DBStrReturn(SCRIPT) <- STRING:
    _I_I_0092017974d65053 [09:04] ASSIGN: __TargetVar(SCRIPT) <- STRING:
    _I_I_0092017974d65053 [09:04] ASSIGN: nTimeout_in(LOCAL) <- INTEGER: 9999
    _I_I_0092017974d65053 [09:04] ASSIGN: sTarget_in(LOCAL) <- STRING: VAG_Skill_B_L@StatServer_Oak.GA
    _I_I_0092017974d65053 [09:04] ASSIGN: sVQ_in(LOCAL) <- STRING: VQ_Skill_B_Tokyo
18:13:26.397_I_I_0092017974d65053 [07:26] HERE IS TARGETS
TARGETS: VAG_Skill_B_L@StatServer_Oak.GA       
18:13:26.397_M_I_0092017974d65053 [13:01] current virtual queue: 101b79cd0 id=299, nVQ=1|39868980-101731c80, priority=0, time=1184750006.397
18:13:26.397_M_I_ [17:0c] VQ(101b96230) created: type=0, tenant=Resources
==========================================
    _M_I_ [17:06] VQ(101b96230) target 101b96340 added: name=VAG_Skill_B_L, location=StatServer_Oak, type=GA, state=##state, activity=unknown
18:13:26.397_M_I_ [10:06] tenant Resources GroupAgents <VAG_Skill_B_L>: statistic ##content with server StatServer_Oak <request=15, status=2> asked
    _M_I_ [17:05] VQ(101b96230) target (name=VAG_Skill_B_L, location=StatServer_Oak, type=GA) synchronizing
18:13:26.397_M_I_ [10:06] tenant Resources Agent <1701>: statistic ##state with server StatServer_Oak <request=17, status=2> asked
    _M_I_ [17:09] VQ(101b96230), target 101b96340: GroupAgents <VAG_Skill_B_L> connected to state Agent 1701
18:13:26.397_M_I_ [10:06] tenant Resources Agent <1602>: statistic ##state with server StatServer_Oak <request=7, status=2> asked
    _M_I_ [17:09] VQ(101b96230), target 101b96340: GroupAgents <VAG_Skill_B_L> connected to state Agent 1602
18:13:26.397_M_I_ [10:06] tenant Resources Agent <1702>: statistic ##state with server StatServer_Oak <request=19, status=2> asked
    _M_I_ [17:09] VQ(101b96230), target 101b96340: GroupAgents <VAG_Skill_B_L> connected to state Agent 1702
18:13:26.397_M_I_ [10:06] tenant Resources Agent <1703>: statistic ##state with server StatServer_Oak <request=9, status=2> asked
    _M_I_ [17:09] VQ(101b96230), target 101b96340: GroupAgents <VAG_Skill_B_L> connected to state Agent 1703
18:13:26.397_M_I_ [10:06] tenant Resources Agent <1802>: statistic ##state with server StatServer_Oak <request=21, status=2> asked
    _M_I_ [17:09] VQ(101b96230), target 101b96340: GroupAgents <VAG_Skill_B_L> connected to state Agent 1802
18:13:26.397_M_I_ [10:06] tenant Resources Agent <1604>: statistic ##state with server StatServer_Oak <request=11, status=2> asked
    _M_I_ [17:09] VQ(101b96230), target 101b96340: GroupAgents <VAG_Skill_B_L> connected to state Agent 1604
18:13:26.397_M_I_ [10:06] tenant Resources Agent <1704>: statistic ##state with server StatServer_Oak <request=3, status=2> asked
    _M_I_ [17:09] VQ(101b96230), target 101b96340: GroupAgents <VAG_Skill_B_L> connected to state Agent 1704
18:13:26.397_M_I_ [10:06] tenant Resources Agent <7999998>: statistic ##state with server StatServer_Oak <request=13, status=2> asked
    _M_I_ [17:09] VQ(101b96230), target 101b96340: GroupAgents <VAG_Skill_B_L> connected to state Agent 7999998

18:13:26.397_M_I_0092017974d65053 [13:02] entering virtual queue "VQ_Skill_B_Tokyo"
    _M_I_ [17:0f] VQ(101b96230) [at all 8 0] 1 target(s), flag=a, guid: 0Resources|VQ_Skill_B_Tokyo|1|-1|1|0|""|||01StatAgentLoading|00{}[]VAG_Skill_B_L@StatServer_Oak.GA
18:13:26.397_M_I_0092017974d65053 [13:03] call (virtual queue 101b79cd0, id=299, priority 0, time 1184750006.397) waits for VQ 101b96230 (name="VQ_Skill_B_Tokyo") now
request to 65202(--) message RequestDeletePair
AttributeReferenceID 2726
AttributeDataKey 'RTargetAgentGroup'
AttributeConnID 0092017974d65053
AttributeThisDN '20719'
..sent to ctisssvp:5080(fd=16)
request to 65202(--) message RequestAttachUserData
AttributeReferenceID 2727
AttributeUserData [101] 00 03 00 00..
'RTargetAgentGroup' 'VAG_Skill_B_L'
'RTargetAgentGroup' 'VAG_Skill_B_M'
'RTargetAgentGroup' 'VAG_Skill_B_H'
AttributeConnID 0092017974d65053
AttributeThisDN '20719'
..sent to ctisssvp:5080(fd=16)
request to 65202(--) message RequestDistributeEvent
AttributeExtensions [82] 00 04 00 00..
'SIGNATURE' 'router'
'NAME' 'URS1'
'VERSION' 'Version: 7.1.001.03'
'CLUSTER' 'URS1'
AttributeUserData [785] 00 1E 00 00..
'DNIS_NUM' '20003'
'CUSTID' 'CID:'
'RRequestedSkills'(list)
'CustomerSegment' 'default'
'ServiceType' 'default'
'ServiceObjective' ''
'DEBUG_GENESYS_DESTINATION' 'Switch_Tokyo'
'Site_ext' 'Tokyo'
'Skillname' 'Skill_B'
'SKILL_CODE' '21030'
'VAR_sTarget_val' '20841_Switch_Tokyo'
'VAR_sStatServer' 'StatServer'
'SubDN' '20777_Switch_Tokyo'
'RTargetRuleSelected' ''
'RTargetTypeSelected' '100'
'RTargetObjectSelected' ''
'RTargetAgentSelected' ''
'RTargetPlaceSelected' ''
'RTenant' 'Resources'
'RStrategyName' 'jump_to_routing'
'RTargetUsed'(list) 'TargetType' '100'
                    'TargetName' ''
'RRequestedSkillCombination' ''
'ReasonToCXU' 'noANI'
'VAR_nResult' '0'
'PegTD' 1
'ScriptName' ''
'VAR_sVQ' 'VQ_Skill_B_Tokyo'
'RTargetAgentGroup' 'VAG_Skill_B_L'
'RTargetAgentGroup' 'VAG_Skill_B_M'
'RTargetAgentGroup' 'VAG_Skill_B_H'
AttributeDNIS '20003'
AttributeOtherDNRole 1
AttributeOtherDN '6001'
AttributeThisDNRole 2
AttributeThisQueue 'VQ_Skill_B'
AttributeThisDN 'VQ_Skill_B'
AttributeCallID 93
AttributeConnID 0092017974d65053
AttributeCustomerID 'Resources'
AttributeReferenceID 4294967295
AttributeUserEvent EventAttachedDataChanged
..sent to ctisssvp:5080(fd=16)
    _M_I_0092017974d65053 [17:0e] virtual queue "VQ_Skill_B_Tokyo"(id=299), VQ 101b96230 (1 targets): SELECT MAX by statistic StatAgentLoading(random )
    _M_I_0092017974d65053 [17:0b] VQ 101b96230 target "VAG_Skill_B_L" (#1, 8-7 components): SELECT MAX by statistic StatAgentLoading(random)
    _M_I_0092017974d65053 [17:0b] component #1 1701: logged out
    _M_I_0092017974d65053 [17:0b] component #2 1602: not ready
    _M_I_0092017974d65053 [17:0b] component #3 1702: logged out
    _M_I_0092017974d65053 [17:0b] component #4 1703: logged out
    _M_I_0092017974d65053 [17:0b] component #5 1802: logged out
    _M_I_0092017974d65053 [17:0b] component #6 1604: logged out
    _M_I_0092017974d65053 [17:0b] component #7 1704: logged out
    _M_I_0092017974d65053 [17:0b] component #8 7999998: logged out
    _M_I_0092017974d65053 [17:0b] VQ 101b96230 target "VAG_Skill_B_L": component was NOT SELECTED (7 1 0)
    _M_I_0092017974d65053 [17:0e] target VAG_Skill_B_L: not ready passed
    _M_I_0092017974d65053 [17:0e] virtual queue "VQ_Skill_B_Tokyo"(id=299), VQ 101b96230: target for routing was NOT SELECTED (0 0 0 1)
  result of SelectDN: STRING: return:timeout
    _I_I_0092017974d65053 [09:04] ASSIGN: sTarget_out(LOCAL) <- STRING: return:timeout
    _I_I_0092017974d65053 [07:27] HERE IS WAIT FOR DN (9999 sec)
18:13:26.398_B_I_0092017974d65053 [07:27] delay treatments for 0 msec
18:13:26.398_M_I_0092017974d65053 [10:1f] pulse for one call
    _T_I_0092017974d65053 [0E:19] check call routing states: state=10 delivery=0 treatment=0 held=0 reserving=0 - true
    _M_I_0092017974d65053 [17:0e] virtual queue "VQ_Skill_B_Tokyo"(id=297), VQ 101b90640 (1 targets): SELECT MAX by statistic StatAgentLoading(random )
    _M_I_0092017974d65053 [17:0e] target VAG_Skill_B_H: empty(1-1 components) passed
    _M_I_0092017974d65053 [17:0e] virtual queue "VQ_Skill_B_Tokyo"(id=297), VQ 101b90640: target for routing was NOT SELECTED (0 1 0 0)
    _M_I_0092017974d65053 [17:0e] virtual queue "VQ_Skill_B_Tokyo"(id=298), VQ 101b81270 (1 targets): SELECT MAX by statistic StatAgentLoading(random )
    _M_I_0092017974d65053 [17:0e] target VAG_Skill_B_M: empty(4-4 components) passed
    _M_I_0092017974d65053 [17:0e] virtual queue "VQ_Skill_B_Tokyo"(id=298), VQ 101b81270: target for routing was NOT SELECTED (0 1 0 0)
    _M_I_0092017974d65053 [17:0e] virtual queue "VQ_Skill_B_Tokyo"(id=299), VQ 101b96230 (1 targets): SELECT MAX by statistic StatAgentLoading(random )
    _M_I_0092017974d65053 [17:0b] VQ 101b96230 target "VAG_Skill_B_L" (#1, 8-7 components): SELECT MAX by statistic StatAgentLoading(random)
    _M_I_0092017974d65053 [17:0b] component #1 1701: logged out
    _M_I_0092017974d65053 [17:0b] component #2 1602: not ready
    _M_I_0092017974d65053 [17:0b] component #3 1702: logged out
    _M_I_0092017974d65053 [17:0b] component #4 1703: logged out
    _M_I_0092017974d65053 [17:0b] component #5 1802: logged out
    _M_I_0092017974d65053 [17:0b] component #6 1604: logged out
    _M_I_0092017974d65053 [17:0b] component #7 1704: logged out
    _M_I_0092017974d65053 [17:0b] component #8 7999998: logged out
    _M_I_0092017974d65053 [17:0b] VQ 101b96230 target "VAG_Skill_B_L": component was NOT SELECTED (7 1 0)
    _M_I_0092017974d65053 [17:0e] target VAG_Skill_B_L: not ready passed
    _M_I_0092017974d65053 [17:0e] virtual queue "VQ_Skill_B_Tokyo"(id=299), VQ 101b96230: target for routing was NOT SELECTED (0 0 0 1)
18:13:26.398_I_I_0092017974d65053 [09:04] <<<<<<<<<<<<suspend interpretator(WAIT_FOR_DN), timers:11000
18:13:26.398_B_I_0092017974d65053 [07:09] start chain of treatments
received from 65202(--)ctisssvp:5080(fd=16) message EventACK
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 414564
AttributeTimeinSecs 1184750006 (18:13:26)
AttributeReferenceID 4294967295
AttributeThisDN 'VQ_Skill_B'
AttributeUserEvent RequestDistributeEvent
18:13:28.006_M_I_ [10:1d] PULSE (calls: 2(2)=2+0-0, targets=2, time=1184750007, mem=0,90117,1402,19,124,0)
18:13:29.267_M_I_ [10:17] CHANGE OF STATE (tenant Resources object 1602 statserver StatServer_Oak)
    _M_I_ [10:17] ready DN(switch Switch_Tokyo, number 6002, type 2, time= 1184750009) for agent 1602, place Place_6002_Tokyo, status WaitForNextCall time= 1184750009
    _M_I_ [10:17] tenant Resources object 1602 statserver StatServer_Oak: 1 ready DNs reported
18:13:29.267_M_I_ [10:15] check queue for statobject <1602> type <Agent>
WAITING CALLS: 0092017974d65053
    _M_I_0000000000000000 [10:20] try to route to agent "1602" (place "Place_6002_Tokyo", 1 ready DNs reported)
18:13:29.267_M_I_ [10:0a] object Place_6002_Tokyo|Resources| is unblocked
    _M_I_ [10:0b] agent 1602, place Place_6002_Tokyo, switch  dn  isn't blocked absolutely(0)
    _M_I_0092017974d65053 [10:21] try to route to agent "1602" (place "Place_6002_Tokyo", 1 ready DNs reported)
    _T_I_0092017974d65053 [0E:19] check call routing states: state=10 delivery=0 treatment=0 held=0 reserving=0 - true
18:13:29.267_M_I_ [10:0a] object 1602|Resources| is unblocked
18:13:29.267_M_I_ [10:0a] object 6002|Switch_Tokyo| is unblocked
    _M_I_0092017974d65053 [01:0d] attempt to route (1)
    _T_I_0092017974d65053 [0E:19] check call routing states: state=10 delivery=0 treatment=0 held=0 reserving=0 - true
========== DN Information ===========
DN Number 6002
Agent Name 1602
Place Name Place_6002_Tokyo
Agent Login 1602
Switch Name Switch_Tokyo
DN Type 2
=====================================
====================== Target Information =====================
Target Name    < VAG_Skill_B_L >
Target Location < StatServer_Oak >
Target Type    < GA >
STATE MAPPING INFO - STATISTIC < ##state >:
Stat Server DN info available
Modelling Statistic  : NOT available
==============================================================

18:13:29.267_X_I_0092017974d65053 [06:04] send to tserver TServer_G3r_Tokyo_2 TReserveAgent (dn=6002@Switch_Tokyo, name=1602, place=Place_6002_Tokyo, priorities=0,3,602)
request to 65202(--) message RequestReserveAgent
AttributeReferenceID 2728
AttributeExtensions [71] 00 03 01 00..
'ar-priority-1' 3
'ar-priority-2' 602
'CUSTOMER_ID' 'Resources'
AttributePriority 0
AttributeTimeout 15000
AttributePlace 'Place_6002_Tokyo'
AttributeAgentID '1602'
AttributeThisDN '6002@Switch_Tokyo'
..sent to ctisssvp:5080(fd=16)
18:13:29.268_M_I_0092017974d65053 [10:1b] blocking: agent 1602, place Place_6002_Tokyo, switch Switch_Tokyo dn 6002 is blocked for 15 sec by 275 expired 1184750024
    _M_I_0092017974d65053 [10:21] LAUNCHED (dn=6002)
18:13:29.268_M_I_ [10:17] CHANGE OF STATE (tenant Resources object 1602 statserver StatServer)
    _M_I_ [10:17] ready DN(switch Switch_Tokyo, number 6002, type 2, time= 1184750009) for agent 1602, place Place_6002_Tokyo, status WaitForNextCall time= 1184750009
    _M_I_ [10:17] tenant Resources object 1602 statserver StatServer: 1 ready DNs reported
18:13:29.268_M_I_ [10:15] check queue for statobject <1602> type <Agent>
WAITING CALLS: 0092017974d65052 0092017974d65052
    _M_I_0000000000000000 [10:20] try to route to agent "1602" (place "Place_6002_Tokyo", 1 ready DNs reported)
    _M_I_0000000000000000 [10:20] try to route to agent "1602" (place "Place_6002_Tokyo", 1 ready DNs reported)
    _M_I_ [10:0b] agent 1602, place Place_6002_Tokyo, switch  dn  isn't blocked absolutely(275)
    _M_I_0092017974d65052 [10:21] try to route to agent "1602" (place "Place_6002_Tokyo", 1 ready DNs reported)
    _T_I_0092017974d65052 [0E:19] check call routing states: state=10 delivery=0 treatment=0 held=0 reserving=0 - true
    _M_I_0092017974d65052 [10:21] agent 1602, place Place_6002_Tokyo, switch  dn  is blocked with call 275 (15 sec from 1184750009)
    _M_I_0092017974d65052 [10:21] try to route to agent "1602" (place "Place_6002_Tokyo", 1 ready DNs reported)
    _T_I_0092017974d65052 [0E:19] check call routing states: state=10 delivery=0 treatment=0 held=0 reserving=0 - true
    _M_I_0092017974d65052 [10:21] agent 1602, place Place_6002_Tokyo, switch  dn  is blocked with call 275 (15 sec from 1184750009)
received from 65202(--)ctisssvp:5080(fd=16) message EventAgentReserved
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 376601
AttributeTimeinSecs 1184750009 (18:13:29)
AttributeTimeout 15000
AttributePlace 'Place_6002_Tokyo'
AttributeAgentID '1602'
AttributeThisDN '6002@Switch_Tokyo'
AttributeReferenceID 2728

[/code]
Title: Re: How does URs handle multi-queue routing?
Post by: cavagnaro on July 24, 2007, 04:11:13 AM
Interesting, and what does StatServer says?
Which PBX are you using? A Nortel?
Can you share your ird strategies? I'll like to test with an Alcatel OXE.
Also would like to try without Virtual Queues.
Title: Re: How does URs handle multi-queue routing?
Post by: victor on July 24, 2007, 05:19:41 AM
Cavagnaro,

I am using Genesys Avaya-simulator and 7.2 StatServer.  I doubt that PBX would matter since routing logic is controlled by URS. One thing that I am curious is we use SelectDN() and SuspendForDN() instead of a bit more standard Select-DN block object... I doubt that it would matter though...

Try several tests and see if you can replicate it. One thing to be careful with is that it seems like if you place call to first then second then the first then the second, it will sometimes be difficult to recreate this problem, so I suggest placing first call into queue A, then place call second call into queue B then let agent receive both calls. Then try placing a call to queue B, wait 1 minute and then place a call to queue A and then let agent get the calls. So, it is A->wait 1 minute->B->get both calls->B->wait 1 min->A->get both calls->B->wait 1 minute->A->get both calls.

Seems to cause the problem almost every time during this sort of sequence.
Title: SOLVED: Re: How does URs handle multi-queue routing?
Post by: victor on August 17, 2007, 07:55:34 AM
Ok, it seems like I figured the problem (and Genesys tech support managed to get back to us about a day later to confirm it  ;D ).

0092017974d65052 has a higher priority than 0092017974d65053 and therefore it should be routed to the agent first, BUT because we use StatServer for Skill_A and StatServer_Oak for Skill_B, URS somehow no longer routes according to priority but what seems to be at random .

So, the lesson is: URS does not take priority of the call when targets are using stats from different StatServers. And this, my friends, makes little sense since priority is maintained by URS and not StatServer, so why in the world would it care about it?

Genesys might call it whatever they want, but in my book, this is a bug.
Title: Re: How does URs handle multi-queue routing?
Post by: URSMan on August 17, 2007, 08:35:05 AM
Vic,

also do not forget that priority is not shared between URS. You can have priority 0 call on URS 1 and priority 100 on URS 2 and still get priority 0 call before priority 100.

[move]URSMan Rulez[/move]
Title: Re: How does URs handle multi-queue routing?
Post by: victor on August 17, 2007, 08:53:45 AM
URSMan,

I don't think it is true. Obviously, URS2 is not informed of priority of call in URS1, but T-Server should be able to distinguish between two by looking at AttributePriority which contains that call's priority level.

As long as it is within the timeout I cannot remember the name of that controls how long T-Server waits for other reservation requests before replying, then T-Server will reply to one and reject the other.

Damn, if I only remembered the option name. I think it was agent-reservation-wait or something like that...
Title: Re: How does URs handle multi-queue routing?
Post by: Kevin S on August 17, 2007, 12:44:24 PM
Victor, it's not a bug, it's an "Undocumented Feature"...
Title: Re: How does URs handle multi-queue routing?
Post by: victor on August 20, 2007, 01:28:35 AM
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?  ::) )
Title: Re: How does URs handle multi-queue routing?
Post by: Kevin S on August 20, 2007, 01:46:39 PM
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...
Title: Re: How does URs handle multi-queue routing?
Post by: Mike Kamlet on August 21, 2007, 03:40:18 PM
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
Title: Re: How does URs handle multi-queue routing?
Post by: victor on August 22, 2007, 02:45:56 PM
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.

Title: Re: How does URs handle multi-queue routing?
Post by: Mike Ksmlet on August 22, 2007, 10:00:06 PM
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
Title: Re: How does URs handle multi-queue routing?
Post by: asanti on August 29, 2007, 05:34:07 AM
How did lowering pull-time from 2 seconds to 1 second helped it?  ???
Title: Re: How does URs handle multi-queue routing?
Post by: Mike Kamlet on August 30, 2007, 08:46:41 PM
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
Title: Re: How does URs handle multi-queue routing?
Post by: victor on August 31, 2007, 07:45:18 AM
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
Title: Re: How does URs handle multi-queue routing?
Post by: Mike Kamlet on August 31, 2007, 09:58:41 PM
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.
Title: Re: How does URs handle multi-queue routing?
Post by: Steph on September 05, 2007, 08:24:36 AM
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!
Title: Re: How does URs handle multi-queue routing?
Post by: mark on September 07, 2007, 04:06:00 PM
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.
Title: Re: How does URs handle multi-queue routing?
Post by: victor on September 10, 2007, 03:48:31 AM
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.