CallTakenOverBySwitch

[Dennis D.]

Anyone had problems with call not handles by UR and defaulting to default DN. We just migrate from MLLINK to SYMPOSIUM Link.
Our set up is :
. Version 6.5
TServer, UrServer, StatServer etc

[Vic]

There are several reasons as to why such a thing might happen.
Some of them are:

1. if ALL the calls are droped to default then you either do not have your routing point properly defined in PBX or URS is not replying within 4 seconds after EventRouteRequest

2. if only some of the calls are dropped to default then chances are your URS is not replying fast enough to your EventRouteRequest. Check your logs and check whether or not the time difference between EventRouteRequest and EventRouteUsed (OtherDN is _____) for the defaulted call is greater than four.

In our centers, we usually start having problems if calls are not processed within 2 seconds after issuing of EventRouteRequest.

[Chris]

Genesys has recommended to us to put 4 seconds of treatment (ringback, music, etc.) right up front at the beginning of every strategy to prevent this from happening.

[Superglide]

The 4 sec ringback may resolve the problem, but at the end of the day if the cause is slow responses, then what is actually making this occur?

[Vic]

Well, there are three billion reasons for it
if you are using MLink then you have a 9600 or 14.4K (please somebody correct me!) for your MLink. That by itself will bring any large system to a standstill. Upgrading to Symposium would give you a faster connection (what WAS the link speed there? 32K?) but it comes with a very old Pentium CPU. Upgrading THAT to the latest CPU would cost you over 200K.

So, you have several ways of handling it
1. upgrade your link
2. modify your mlink settings in TServer and specify the messages you want your link to transmit (otherwise you would be getting everything)
3. review your current DN plan and call flow and see if callflows can be combined
4. review your Genesys configuration and see if load balancing is in order (LDS is a really cool tool)
5. review your strategies and see if you are issuing SOME KIND OF treatment command as soon as call is entered. Keep in mind, that even though PBX timeout is around 4 seconds, in real life, if there is no reply within two second, PBXs usually have a tendency to handle the call themselves.

Chances are, as soon as you add uncoditional treatment to all calls entering RP, you will fix your problems. Check that one first and tell us if it worked!

[Superglide]

A 32k link!!!! I guess we are spoiled here with the Ethernet connection that the AVAYA MapD card supprts.

The slow link speed would certainly mean it would have to be taken into consideration when designing such systems wrt to RPs and Strategies.

[Dennis D.]

Thank you every one for your kind help on this matter. we did verify Link connectivity, and reported to be very efficient.
We also verify Strategy and found no treatment being the cause of the problem. We also generated a RingBack treatment right up front.
All of this did not help at all. We made some call flow analysis in our call center and discovered something interesting :

1) The customer call was initially treated by UR succesfully and sent to an IVR where all DNs where registered in CME, so far so good.
2) In some exception, the IVR was transfering the calls to a call center, using a CDN not acquired by Genesys, and where none of the agent where defined in Genesys. Again so far so good, the customer call was treated conveniently.
3) When one of these agents tried to transfer to another call center, this one acquired by TServer and where agents are all defined in CME, the call was not treated by UR, but defaulted to the default DN.

Conclusion :
We fixed the problem by defining all ACD of all our Call Center into CME.

Voilà

Hope this update on the problem will help others.

Thank you

Dennis

[Kevin]

We had issues when we first upgraded from 6.1 to 6.5. BUT.... read on before swearing off (or at) 6.5...

Our environment was RP > IVR > RP > Strategy. Initially, host issues caused the IVR to increase transfer time, so we set route_consult_call = true, and all was fine and dandy.

When we upgraded to 6.5, TServer processed calls faster, such that the call was processing, routing to VTO, then trying to transfer the call to an agent before the IVR had dropped off the line. (The ol' "Cannot transfer a call that is in a state of conference/transfer" trick)

We were able to resolve by setting route_consult_call = false and give_ringback = true. Now, since the switch is getting treatment, it doesn't matter how long the call remains (figuratively) in the consult/conference state, the routing doesn't start until the consult call is complete.