Waiting Time & Routing

[genecool]

Hi everyone,

In order to not interrupt the calculation of waiting time I try to find a way to route a call between two site without deleting the virtual queue.

In fact, the call enters in the virtual queue in the site A then is transfered to site B before distribution. I would like that the calculation of the waiting time starts from site A when it is entered in the virtual queue.

Firstly, I used TRoute function but it removes the call from all virtual queues

Have you any idea ?

[kubikle]

Most likely possible options are:
- not to use for this virtual queus at all (if this waiting time is needed for follwing routing for example then other approaches based on attached adat for example might work)
- use URS virtual queue support - in such case the same strategy need to continue call processing after call is moved to site B. Intermediate (not final) "routing" which do not result automatic exit from virtual queeus normally can be done with DeliverCall function. This function can move call to another site after what the strategy can continue and make final routing for example (quite similarly to how it happen when IVR treatment is used)
- immitate Virtual queue events with SendEvent function (on your own risk as manually keeping Virtual queue events balance can be quirte a chalenge).

[mduran22]

If you have ISCC licenses you could route between sites as mentioned below by flowing to multiple targets within the same strategy. Do not use the clear targets if you want to continue to target and wait in both virtual queues. One other way to measure this if you use call conn or informart (or aggregated numbers in CCA) is to use the call cleared statistic to measure quantity and time of calls that have cleared the queue (wait time is over and call TRoutes).

Mike

[genecool]

In fact, I have one T-Server 8.0, one SIP Server 8.0 and ISCC.

SIP Server is used such as IVR gateway for GVP and T-Server is the main telephony server.

First, calls arrive on T-Server and then transferred to SIP server for treatments.

Next, calls enters into VQ before to be route to T-Server for distribution. T-Server is used for distribution in order to use busy treatment on IPBX.

I do not want that strategy on SIP Server continues after transfer and that the calculation of Waiting Time in VQ is reset.


To view statistics in real time I use CCPulse. So I want the wait time is calculated for each call with the time spent on the SIP Server and T-Server and thus obtain the real Max Waiting Time.


I tried to use target block without clear target and DeliverCall function... nothing works.


The workaround would be to calculate the waiting time on the T-Server only, but whether any solution exists I would be interested to know it.


Thanks.

[René]

Hi genecool,

There is new hotfix available for URS 8.1 that might help you as it allows you to control when URS generates EventDiverted. Please read release notes of URS for more info.

R.

PS. I had no chance to test it so no guarantee

[kubikle]

Router keeps VQ balance and if Queeued was sent in processing of call then Diverted will be sent during startegy run for this call.
When second strsategy start for some call the first one must be completed/aborted and that means distributring of Diverted for VQ.
The only exception known to me - call while processing by URS (but before call is routed) is somehow (unexpactedly for URS) moved to another DN where some strategy is loaded and option use_ivr_info is set to true. This new strategy will be started and information about all VQ call entered will be passed to this strategy run (so it can later distribute Diverted).

As result the ugly way to do it: 2 URSes and 3 strategies. When call on SIP both URSes start strategies (the same RP has 2 different loaded strategfes for different URSes):
URS1 make real processing (no VQ it uses). URS2 do nothing - just enter into VQ and long Delay.
URS1 move call to TServer where strategy for URS2 is loaded. URS2 terminate current strategy with preserving call in VQ (for URS2 it looks like unexpected call moving from SIp to Tserver)