Waiting calls no longer existing

[Lorenzo]

Hi all,

We sometimes have Waiting calls which seems to stay in the Virtual Queue (can be seen under CCPulse+) but in fact these calls do not exist anymore : apparently, there are sometimes events through the network which are not sent.
This is annoying for the supervisors and we are trying to find a solution : we basically do not want to see the calls that wait longer than 20 minutes.
The statistic used is a CurrentNumber of CallWait

Is there a way to do that with Actions and Thresholds : we've looked but we did not found a way yet.
Would there be a way through the Routing Strategies : by checking for example the time a call has spent in queue, if he spent more than 20 minutes then we would attach a data and we would filter on this to exclude it in CCpulse+ ? But would we have to do a loop in the strategy during the queueing ?

Many thanks in advance for your help

[mark]

Good old 'Ghost calls'!

We did something similar in my old place of work, but unfortunately im not sure how it was achieved.

[LeszekM]

Lorenzo,

I think you should try using time range (like  (0,1200) - this is in seconds ) with the statistic of CurrentNumber of CallWait.

Regards,
Leszek

[Lorenzo]

In the definition of the CurrentNumberWaitingCalls, the TimeRange cannot be used : it's gray and you cannot enter any value. I guess this is related to the fact that we are monitoring "current Number of interaction".

Any other idea or solution would be appreciated.

[LeszekM]

Yes, you are right. :-)
So in CurrentNumberWaitingCalls definition the Category should be changed to CurrentNumberInTimeRange.
Then it is possible to enter the timerange and it works as you expect.

Leszek

[Kevin S]

I'm not sure what versions you are running, but...
There are some known issues one of the versions of URS 7.0 (I think 7.0.101.03) where, if you make ANY changes to a Virtual Queue (including creating one), it can cause the URS to temporarily "lose Virtual Queue support" while trying to route a call to an agent.

Once we were able to pin this down and started making our VQ changes outside of business hours, we drastically reduced the number of Phantom calls - at this point, they are almost non-existent.

[victor]

Lorenzo,

last year, one of our clients who had several sites all sharing the same URS was experiencing the dreaded ghost-calls-in-queue.

We tried "check-stuck-in-queue" only to find out that it does not work virtual queues, we tried changing the carrier that connects the sites, we tried upgrading - nothing worked.  Then we upgraded from 6.5.xxx to 7.1.xxxx and 90% of the ghost-calls were gone.

I am not sure why, but StatServer becomes dillusional when then order of events are sometimes do not come in the way it expects. This is especially true for TRANSFERED calls, where agent initiates a consult-call to routing point, is queued, connected to operator, and THEN completes the call. This also held true for some instances where call was completed while consult-call was queued.

What we did is added another routing point BEFORE the routing point where call was queued. The stop-gap routing point would just get the call, and forward it to the routing point with VQ. Adding 2 seconds before throwing adjunct on that stop-gap RP got rid of all our ghosts.

Of course, this is for Avaya G3 and POSSIBLY Avaya S8700 PBXs, but it would be worth a try - try adding an additional routing point before the one where you queue the call, put a 4 second delay (for right now) before issuing an adjunct, and then have a strategy on that RP that would route the call to your routing point with VQ on it. See if you get rid of your ghost calls this way.

You can also use Genesys TestPhone to issue EventAbandoned for the calls that are stuck, making StatServer removing them from memory.

Please tell me if you need help with that.

Or, if it is really bad, a simple app that would track StatServer logs for stuck calls and issue EventAbandoned for all the fake ones.

BTW, did you ask Genesys WHY you are getting ghost calls? I mean, it should not be there in a first place and perhaps a simple upgrade would fix it.

[Gauthier Delmee]

Hi All,
Since version 7.1 genesys has implemented a series of measures to delete stuck calls from T-Server, URS, StatServer. The one I have found most successful so far is the sample script that comes with Solution Control Server (it requires to have perl on the server) but allows to control any number of T-Server and also allows to have a log of stuck calls in XML format.
Genesys has also implemented a new event to be able to avoid an impact on reporting.
Otherwise this can be controlled directly on each t-server through some of the options or through SNMP if you have that feature available.

Gauthier

[Peter K.]

Gauthier - thank you for your post! 
What can you please tell me more about it? Can you please describe these scripts? Where do we find them? What exactly can they do? Which manual talks about it?

PK