virtual queue statistics

[ragh]

Hi,

In our network call is first handled by network t server (Genspec) from where it is sent to IVR RP. 
The strategy loaded in IVR RP targets the agent by skill in the premise side.  We use virtual queue and hence, the calls would be put in to the respective queues configured for skill (VAG) before it goes to the agent.
Only when URS finds an agent it instructs IVR server and hence the GVP to give the call back to the network switch (network T Server) from where it goes to the premise side (SIP Server).
In short, the call goes to the Agent from virtual queue of the premise switch (maintained at strategy running at IVR RP) via network IVR RP, Network T Server RP, Premise RP.  In this case, the [b]CallAnswer[/b] statistic of virtual queue doesn't increment. The counter always shows zero. When we checked the statserver logs, it shows the EventEstablished message of the respective Agent DN with [b]This Queue[/b] parameter as the premise RP from where it has gone to the Agent. Whereas, we are able to get CallsWaiting, CallAbandoned, CallCleared statistics, as we could see the proper messages from premise SIPServer.
Since we are doing network level routing and the virtual queue of the premise is being maintained at network level,
appreciate if any help is provided in populating the virtual queue statisctics.

Thanks & Regards,
Ragh

[tony]

OK,

A VQ cannot "answer" a Call, it can only Distribute it - the [i]Agent [/i] "answers" the call...

If you want to use a VQ to determine call volumes, your statistic [b]CallAnswer [/b] should be replaced by [b]CallDistributed [/b] (and, if you want to count everything properly, add in [b]CallAbandoned[/b], too)

Tony

[cavagnaro]

Hum sorry Tony but CallAnswered is a retrospective statistic which has the facility to travel backwards to the RP or VQ who distributed the call. However for that to work on CME on the Agent Group you should add as Orig DN the VQ or RP respective. So, you can get CallsAnswered from a VQ or RP.
Remember that a CallDistributed is not necesarrily to an agent and if so it doesn't mean that he answered it, the call could abandon on ringing. You can also distribute a call to another RP and if you assume that as answered well could be completely wrong and give wrong interpetrations of statistics.

Regards

[tony]

Hmmm... I'm guessing my brain was elsewhere, yesterday - this is the second retraction I've had to type, today!

You are, of course, correct cavagnaro and I apologize to ragh...

...ragh still has a problem, though... 

Tony

[ragh]

Hi,

Cavagnaro, I already had this VQ mapped as origination dn to the Agent group.

Tony/Cavagnaro,  As mentioned earlier, the call going to the agent at premise level after, it passes IVR RP, Network T Server RP and the Premise RP.  In this scenario the call answered is not getting populated. Request your assistance.

Thanks

Regards,
ragh

[cavagnaro]

Sorry ragh but I don't understand, do you think you can draw it and show us?
Thanks

[eugene]

Ragh, I might just be pointing out the obvious, but can you try the following:

Register the Virtual Queue in a StarterApp (SupportPhone) etc.

Put your agent in Not Ready

Place your test call and see if it'll queue against the VQ

Eugene