Hmm, changing that option prevented any calls being routed. I get a DN Busy error after the RequestRouteCall:
22:45:11.066_T_E_ [14:0c] EventError is received for tserver SIPTS_81[SIP-01] - DN is busy
22:45:11.066_A_E_010d02111e479014 [14:32] <-----------ERROR
22:45:11.066 Std 21003 interaction 010d02111e479014 routing error 0231 DN is busy
22:45:11.066_M_I_010d02111e479014 [17:11] VQ 0000000002692520 first available call: 010d02111e479014, reason=strategy
_T_W_010d02111e479014 [0E:0f] emergency: reroute call due to this error
_I_I_010d02111e479014 [01:0f] binding with Target 0000000000000000 (VQ 0000000000000000)
22:45:11.066_M_I_010d02111e479014 [10:2f] RStatCallsInQueue update: object <8013>(1558), type CfgDN value 0+0+0, reason <not a target>
22:45:11.066_M_I_010d02111e479014 [10:2f] RStatCallsInQueue update: object <TTrain1>(344), type CfgPerson value 0+0+0, reason <not a target>
22:45:11.066_M_I_010d02111e479014 [10:2f] RStatCallsInQueue update: object <Place_8013>(263), type CfgPlace value 0+0+0, reason <not a target>
_I_I_010d02111e479014 [01:10] binding with Target 0000000000000000 (VQ 0000000000000000)
_I_I_010d02111e479014 [07:0a] HERE IS WAIT (2 sec)
22:45:11.066_B_I_010d02111e479014 [07:0a] delay treatments for 0 msec
22:45:11.066_M_I_010d02111e479014 [10:1f] pulse for one call
_T_I_010d02111e479014 [0E:19] check call routing states: state=4 delivery=0 treatment=0 held=(0 0) reserving=0 ivr=0 - true
22:45:11.066_M_I_010d02111e479014 [17:0e] VQ 0000000002692520 (virtual queue "TRAIN_DEFERRED_WORK_LEXUS_VQ", id=29), (1 Targets): SELECT MAX by statistic <StatAgentLoading>(random )
_M_I_010d02111e479014 [17:0b] VQ 0000000002692520 Target "?:Train_Out_Toyota_Service = 1"(000000000200ed50) #1, (2-1 Components): SELECT MAX by statistic <StatAgentLoading>(random )
_M_I_010d02111e479014 [10:0c] agent TTrain1, place Place_8013, switch dn is blocked with call 1000000001 (3 sec from 1343771110)
_M_I_010d02111e479014 [17:0b] VQ 0000000002692520 Target "?:Train_Out_Toyota_Service = 1"(000000000200ed50) Component #1 TTrain1: not valid
_M_I_010d02111e479014 [17:0b] VQ 0000000002692520 Target "?:Train_Out_Toyota_Service = 1"(000000000200ed50) Component #2 TTrain2: logged out
_M_I_010d02111e479014 [17:0b] VQ 0000000002692520 Target "?:Train_Out_Toyota_Service = 1"(000000000200ed50): Component for routing was NOT SELECTED (1 0 1 0)
_M_I_010d02111e479014 [17:0e] VQ 0000000002692520 Target "?:Train_Out_Toyota_Service = 1"(000000000200ed50): not ready passed
_M_I_010d02111e479014 [17:0e] VQ 0000000002692520 (virtual queue "TRAIN_DEFERRED_WORK_LEXUS_VQ" id=29): Target for routing was NOT SELECTED (0 0 0 1 0)
22:45:11.066_B_I_010d02111e479014 [07:64] start chain of treatments
received from 65200(SIPTS_81)i407svap02:3000(fd=) message EventAbandoned
This is Genesys’ advice on the issue:
OCS takes into the account the voice Extension DN status only. Here are complete details:
OCS.20120730_213854_404.log
StatServer reports the Place status:
21:45:45.463 STAT_EVENT SEventInfo was received: RequestID: 14, UserRequestID: 263
AgentID: TTrain1
PlaceID: Place_8013
Status: CallInbound [22]
nDNs: 2
LoginID: 9017
DN: 8013, RealDN: 8013, Extension, WaitForNextCall, nActions 1:
tmStart: 1343679302, Action: LoggedIn [2]
pData: ConnID: 0000000000000000, DNIS: null, ANI: null, pUserData: 00000000.
DN: email, RealDN: email, Unknown, CallInbound, nActions 1:
tmStart: 1343679296, Action: LoggedIn [2]
pData: ConnID: 0000000000000000, DNIS: null, ANI: null, pUserData: 02f9d7f0.
The Place_8013 has two medias:
voice DN 8013 in WaitForNextCall status
email DN in CallInbound status
However OCS by design takes into the account statuses for DNs of type Position, Extension and Voice Treatment Port. The Place or email media status is not used by OCS.
As the DN 8013 is in WaitForNextCall status, the predictive call is initiated by OCS.
The blending of voice DNs used by outbound campaign and multimedia medias (like chat, email) has not been tested according to Engineering.
We suggest provisioning separate places for agents that
handle outbound voice calls and for agents that handle inbound emails.
So apparently blending of outbound and multimedia interactions is not possible. Inbound and outbound voice is fine, as is inbound voice and email, but not outbound voice and email.
Fairly major oversight for a solution that markets itself based on its universal routing and blending capabilities!
Unless there’s a way of having emails route to the same DN (8013 in this case) as the voice, or to some other shared DN, it doesn’t seem like it will work.