Genesys CTI User Forum

Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: yahoo on May 29, 2009, 08:14:39 PM

Title: call routed to ACD
Post by: yahoo on May 29, 2009, 08:14:39 PM: connid: 00f201b181998e17

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

Thanks,

[attachment deleted by admin]
Title: Re: call routed to ACD
Post by: ecki on May 30, 2009, 01:27:48 PM: 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.
Title: Re: call routed to ACD
Post by: bcyk on May 30, 2009, 03:47:40 PM: 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
Title: Re: call routed to ACD
Post by: yahoo on May 30, 2009, 10:27:40 PM: [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.
Title: Re: call routed to ACD
Post by: bcyk on May 31, 2009, 04:07:43 PM: 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.
Title: Re: call routed to ACD
Post by: borkokrz on June 01, 2009, 07:09:43 AM: 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 ??
Title: Re: call routed to ACD
Post by: yahoo on June 01, 2009, 01:29:52 PM: 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.
Title: Re: call routed to ACD
Post by: borkokrz on June 01, 2009, 01:53:35 PM: 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.
Title: Re: call routed to ACD
Post by: yahoo on June 01, 2009, 03:30:59 PM: Thanks borkokrz ! It helped me
Title: Re: call routed to ACD
Post by: victor on June 02, 2009, 02:25:11 PM: I see I am too late - the problem is probably you do not have anything set for handling queue timeouts. Definitely Borkokrz is right :)