call routed to ACD

[yahoo]

connid: 00f201b181998e17

can any one please let me know why this call went to ACD? attached are the logs

Thanks,

[attachment deleted by admin]

[ecki]

Hi,

How do you know it went to ACD and when? You would have to provide more information about whole case before we could start looking at this.

e.

[bcyk]

See attached excel file generated by callflow, a program by Genesys
(to get an copy, please make a request to your Genesys support/supplier)

G:\logs>callflow -x 00f201b181998e17 tserver_symposium.log.* out.csv
Reading 100% complete (tserver_symposium.log.20090529_143813_224.log - 1 of 2)
Reading 100% complete (tserver_symposium.log.20090529_145921_669.log - 2 of 2)
Writing 100% complete


There are 6 DNs in this ConnID
'60624' '66626' '60690' 'gskcrcoption81c::' 'VQ_FIELDOPERATIONS' '66633' '64100' '66006'

If the DN 66066 is Position DN, it seems that the ACD call is transferred by 66633 via ACD queue 64100.


What are their DN types in Genesys CME and Norel switch?

In Nortel siwitch, there are 2 DNs per agent seat; Extension and Position

In normal URS, the call is routed to Extension DN unless there is numbering translation from DN to ACD queue.

Is 6606 Position DN?
The 66633 is Extension for VTO (busy announcement)?
Is 64100 ACD queue in Nortel switch?

In addition,
  -> there are replicated RequestGiveRingBackTreatment at 60624, 60690
      -> either remove URS option give_treatment or the equivalent function in URS strategy
      -> it is fine to leave it but log messages are a bit messy
  -> at DN 66006, the DN may be configured as auto-answer (named forced-in in Nortel switch)
    -> client application requests answer to an already-connected call
        -> it is fine to leave it but log messages are a bit messy and confusing

[yahoo]

[quote author=ecki link=topic=4257.msg18951#msg18951 date=1243690068]
Hi,

How do you know it went to ACD and when? You would have to provide more information about whole case before we could start looking at this.

e.
[/quote]

calls are not getting routed to agents bussiness line. 64100 is a ACD Q.

66006 is the agents extension who answered the call from ACD (64100)

66626, 66633 are a VTO ports. 60690 is the cdn on which the stratergy is loaded.

when this call routed to ACD agents were available.

* not all calls landing on this stratergy are routed to ACD's. most of the calls are routed to extensions (bussiness lines) randomly calls are getting routed ACD.

please advice what is causing this issue.

[bcyk]

Pls check URS configuration and debug log

The URS default destination (at application or CDN/RP level) might have set to 64100.

When URS strategy encounters error, the current interaction will be routed to this preset destination.

[borkokrz]

Some event's have extension pair:  DEFAULT#' '64100, so I assume that this is some kind of default destination (as bcyk mentioned). Can you also upload URS logs for this call ??

[yahoo]

please find the URS log for that connid

Also, DEFAULT#'  '64100, is a default destination Q configured so the call can land if there is some issue with routing Stratergy.
But, my question is if there is a problem then all the calls must be routed to 64100. this is happening randomly and i am not able to produce this scenario if i make test calls myself.

[borkokrz]

It looks like the call waits for FieldOperations > 4 on VQ_FIELDOPERATIONS for 120sec and then it is routed to default destination.

14:59:47.987_I_I_00f201b181998e17 [07:07] HERE IS TARGETS
TARGETS: ?:FieldOperations > 4@crcstatserverur.GA
14:59:47.988_M_I_00f201b181998e17 [13:01] current virtual queue: 1860b50 id=9292, nVQ=2|91cfb0c-1086bf0, priority=10, time=1243623587.988
14:59:47.988_M_I_00f201b181998e17 [13:02] entering virtual queue "VQ_FIELDOPERATIONS_gskcrcoption81c"
    _M_I_ [17:0f] VQ(17f2f60) [at all 7 0] 1 target(s), flag=2a, guid: 0Resources|VQ_FIELDOPERATIONS_gskcrcoption81c|1|-1|1|0|""|||01StatTimeInReadyState|00{}{}[]?:FieldOperations > 4@crcstatserverur.GA
14:59:47.988_M_I_00f201b181998e17 [13:03] call (virtual queue 1860b50, id=9292, priority 10, time 1243623587.988) waits for VQ 17f2f60 (name="VQ_FIELDOPERATIONS_gskcrcoption81c") now
    _I_I_00f201b181998e17 [07:0a] HERE IS WAIT (-1 sec)
    _I_I_00f201b181998e17 [07:0a] HERE IS WAIT (120 sec)

15:01:47.997_I_I_00f201b181998e17 [07:08] wait time is over
15:01:47.997_I_I_00f201b181998e17 [09:05] >>>>>>>>>>>>resume interpretator(0)
15:01:47.998 Int 20003 interaction 00f201b181998e17 is routed to default

You should look at target object in URS strategy and increase the timeout or implement some handling to this situation.

[yahoo]

Thanks borkokrz ! It helped me

[victor]

I see I am too late - the problem is probably you do not have anything set for handling queue timeouts. Definitely Borkokrz is right