get ThisDNRole in routing

[vma]

Hi,

Is it possible to capture AttributeThisDNRole in a routing strategy? I would like to take different decision based on this info.

Thank you,
Mihai

[René]

Hi Mihai,

Yes, it is possible using GetRawAttribute[] function that was introduced in URS release 8.1.1.

R.

[vma]

Thank Rene but unfortunately my customer is still using URS 7.6
My issue is that if a monitoring call is not picked up by supervisor it is sent to Rona strategy. I want to disconnect such calls in Rona and not re-inject them in the system.

Thanks

[René]

Monitoring call is automatically generated call to test that the platform works correctly? Would not it be possible to identify such call using caller's number?

R.

[vma]

I mean when a supervisor is silent monitoring an agent. The moment the call arrives on the agent, the supervisor is invited to a conference  (EventRinging on supervisor DN - muted of course). But the supervisor doesn't pick up so this leg of the call goes to Rona and it is sent to another agent. I want to release this call not send it to Rona.

Example:

Supervisor1 is silent monitoring agent1
agent1 receives call and supervisor1 is invited to conference.
supervisor1 doesn't pick the call for 15 seconds
call is sent to rona and supervisor1 is put on not ready
from rona call is sent to agent2 who will hear the conversation between agent1 and customer

Mihai

[René]

Could you post here EventRouteRequest for such RONA call?

R.

[vma]

Rona is triggered by SIPServer (option agent-no-answer-overflow in the TServer section) so there is no RouteRequest.
Here is the EventQueued on the Rona DN

@12:51:34.4370 [0] 8.0.300.38 distribute_event: message EventQueued
AttributeEventSequenceNumber 00000000003998ee
AttributeTimeinuSecs 437000
AttributeTimeinSecs 1381495894 (12:51:34)
AttributeExtensions [23] 00 01 01 00..
'BusinessCall' 1


AttributeThisQueue '8921'
AttributeThisDNRole 10
AttributeThisDN '8921'
AttributeANI '****'
AttributeDNIS '8901'
AttributeUserData [1137] 00 27 00 00..
'GVP-Session-ID' '8FFAC3E6-3128-4807-88AA-EF576F3FF55A;gvp.rm.datanodes=2;gvp.rm.tenant-id=101_test_main_IVR'
'language' 'tw'
'languagecode' '2'
'languageivr' 'pt-PT'
'service' 'blackberry'
'ivrmaxtries' '3'
'ivrcodec' 'mulaw'
'longani' '****'
'vip' 'novip'
'ooh' '0'
'GVP-Session-Data' 'callsession=8FFAC3E6-3128-4807-88AA-EF576F3FF55A;2;0;;;;Resources;test_main_IVR;'
'__reason' 'exit'
'__reason' 'exit'
'LBR_ORIG' '101:132'
'LBR_TS' '495794125'
'LBR_SNUM' '54530'
'RRequestedSkills'(list)
'CustomerSegment' 'default'
'ServiceType' 'default'
'ServiceObjective' ''
'Priority' '2'

'RVQID' 'URP2T3FJM161913TMEIS3Q0H5S00P3K1'
'RTargetTypeSelected' '2'
'RTargetRuleSelected' ''
'RTargetObjectSelected' 'blackberry_novip_tw_VAG'
'RTargetObjSelDBID' '202'
'RTargetAgentSelected' '10325'
'RTargetPlaceSelected' 'Place_3022'
'RTenant' 'Resources'
'RStrategyName' 'URS-blackberry-GLO-CMR008-b'
'RStrategyDBID' '253'
'CBR-actual_volume' ''
'CBR-Interaction_cost' ''
'CBR-contract_DBIDs' ''
'CBR-IT-path_DBIDs' ''
'RRequestedSkillCombination' ''

'RTargetRequested' 'blackberry_novip_tw_VAG'
'PegAGblackberry_novip_tw_VAG' 1
'CallUUID' 'JCRCR99O3D59D8FGTLFKA2NLJS003JNP'
AttributeCallUUID 'JCRCR99O3D59D8FGTLFKA2NLJS003JNP'
AttributeConnID 00d1023451d56db4
AttributeCallID 118521
AttributePropagatedCallType 2
AttributeCallType 2
AttributeCallState 23
AttributeOtherDNRole 1
AttributeOtherDN '***'
AttributeThirdPartyDNRole 10
AttributeThirdPartyDN '30002'

if a call from customer arrives in Rona it is identical with only the DNRole different (it's equal to 2)

[René]

SIP Server allows you to override agent-no-answer-overflow on Agent Login object so you can either disable No-Answer or send such calls to different RP for the supervisors. Would this work for you?

R.

[vma]

yes I though of that, it could be a temporary solution but unfortunately the supervisors are taking customer calls also when there are too many calls in queue so this would disable rona for these calls also.
I though also for two logins for them, one as supervisor and one as agent to avoid the above issue.

It all gets down to AttributeThisDNRole. The supervisors can receive monitoring calls and inbound calls. I need to be able to differentiate between them. If I could capture the value of AttributeThisDNRole in the rona strategy I would just disconnect the calls when the value is 10 and re-inject the calls to the system when it is 2.

[kubikle]

Unlikely will be possible to dn role info with 7.6 router.

Not sure but may be some other approach can be used - like comparing agent that was selected for routing (info about agent can be placed in call user data from routing strategy) with DN where ringing happen (if they match then it is agent or supervisor playing agent and rona can be enabled), if not then it is monitoring.