Genesys CTI User Forum

Are you running in hotstandby or warmstandby? What PBX?
What product versions are you using?
Are the agents not receiving calls only from URS?
If so chances are statserver is missing out on some of the events.
If not, thenwhat you should do, is add addp protocol, and make sure that you are using ActiveX6.x and not its 5.x predecessor, because ActiveX5.x does not support this functionality.

In ActiveX 6 a new event was added to notify softphone that TServers have been switched.
BackupInit, BackupComplete are two of the events you should watch for in your softphone.
By the way, do you still experience this problem if you use Genesys Starter App?


Or if you are using TLib,here is what manual has to say:
Starting with release 6.0, TServer can operate in two modes, warm standby and hot standby, to provide a client application with connection to more than one TServer. In warm standby mode, a client initially connects to one, primary TServer; if the primary TServer fails, the client receives EventServerDisconnected and
attempts to establish a connection to the second, backup TServer. In hot standby mode, a client establishes connections to both the primary and backup TServers; if the primary TServer fails, the backup TServer is assigned the primary role by Management Layer or TBSC. TLibrary on the client side, then, automatically switches the client over to the new primary TServer. The redundant TServers preserve and synchronize call information between them to minimize any losses in case the primary fails.
In both modes, the client must keep a list of all available TServers. If TServers are in warm standby mode, the client attempts to connect to the next TServer on the list as soon as the connection to one of the TServers has been lost. If TServers are in hot standby mode, the client attempts to connect to the backup when it cannot connect to the primary TServer. If the primary TServer fails while operating in hot standby mode, the client does not notice the failure because the backup TServer handles client requests instead. This section presents the TLibrary functions used for hot standby mode.

Note: When a client connects with the backup TServer but cannot connect to the primary TServer after
several attempts, it closes the connection to the backup TServer and restarts the connection procedure to both
TServers.

The functions are:
TSyncSetSelectMask
TSyncIsSet
TSetSocketChangeCallback

I was able to reproduce the problem.
The cause of the problem seems to be ... yes, you are right Stat Server. It seems like Stat Server gets confused about the state of some of the places after TServer switches.

Have you contacted Genesys about it? I think that this will affect all the people that are using hotstandby.

By the way, about the hotstandby are you using two ASAI links and two HA proxies? And if so, where does your second TServer connect? Is it connected to a first HA proxy or second one?

I am a little bit confused about what can be done with HA and what can't.

You see, I know that HA proxy can have a hotstandby redundancy, therefore, I was thinking that if we have two ASAI links, two HA proxies and two tservers we then would have the following layout:
1. HA proxies are in hotstandby mode.
2. TServers are in hotstandby mode
3. Connection for primary TServer specifies HA primary.
4. This causes backup TServer to get connection to primary HA proxy as well.

So, then, both primary and backup TServer are connected to primary HA thus primary link...

Is this the same layout as what you are using or do you have two TServers connected to independent HA proxies which see different links?