" /> how to deal with calls in queue when TServer crash - Genesys CTI User Forum

Author Topic: how to deal with calls in queue when TServer crash  (Read 3112 times)

Vic

  • Guest
how to deal with calls in queue when TServer crash
« on: January 01, 1970, 12:00:00 AM »
Advertisement
Hi, guys,

this topic mainly focuses on how to handle calls that were placed into a virtual queue by URS on Avaya.

In order to provide music for calls on queue, all of us who are blessed with having to deal with the lack of treatment in Avaya do the following:

1. create a music VDN
2. create a routing VDN
3. specify music VDN as treatment for calls that are waiting on a routing VDN in VQ_A

The problem arises when one of Genesys components fails and we are stuck with calls that are forever parked on a music VDN and there is nothing that can be done to retrieve it.

First of all, the layout:

two TServers in warmstandby
two URS in warmstandby

the callflow:

VDN 20100: main routing VDN queing call in VQ_A and providing treatment through VDN 20200
VDN 20200: music VDN

music VDN is set as follows:
1. throw adjunct
2. play music forever


the test:

1. placed a call to 20100
2. call is in VQ_A and is listening to music
3. kill primary TServer

here is what happens:
it notices that primary TServer went down
it queues RequestDistributeEvent (0x58) for the call in VQ_A
URS primary connects to backup TServer
it registers DNs
it issues RequestDistributeEvent for the call in VQ_A
the call is no longer in VQ_A not is monitored by URS but it is nicely parked on 20200 and there is absolutely nothing you can do to retrieve it unless you manually issues RequestRouteCall.

I tried looping the music VDN, so that after playing the music for 3 mins, it would issue an adjunct and then play music again. This did not work URS would just say that no strategy is assigned to this VDN and let PBX handle it. But since after adjunct we have music, obviously PBX just will keep on playing music.

I tried assigning default DN to this music VDN in CME it did not work either.

Here is what I found that works:

1. loop the vector for the music VDN so that it issues adjunct every 5 minutes and then keeps on playing music.
2. load a strategy on music VDN which would route the call back to the routing VDN (in this case 20100).

I know it sounds crazy, but it works:
when you apply treatment to the call and send it to VDN 20200, URS gets EventRouteRequest, but it ignores it, because it knows that this is a treatment. It keeps on ignoring it as long as call is queued.
when TServer crashes and URS is forced to switch to a backup TServer it conveniently forgets about this call. So, when the call on VDN 20200 issues EventRouteRequest, it treats it as a new request and runs the strategy assigned to 20200, thus moving it to where you want it go in case of failure.

I was wondering if there is a better way to handle this, because I am sure I am not the only one who is having major headaches with trying to recover a call from music VDN in case of URS crash, TServer crash and so on. Is there a simpler way to do it? Like having a nice music vector which will actually do what we need?

I posted a similar question earlier on, and based on replies and vectors, none of them actually managed to resolve this problem...

I was wondering if I am forgetting something too obvious...

Vic