Team,

Have developed CTI client using JTAPI for AES 6.x version. Code is working properly. But in actual the site has two AES servers working in HA mode. I have configured both server's address using 'System.setProperty("com.avaya.jtapi.tsapi.servers","first_AES_ip:port,second_AES_ip:port")' So at the time of Agent login, program will load the services from servers(which ever is up) and use the respective tlink to proceed further with CTI functionalities(call control, agent state change, agent logout etc.)

My query:-
Suppose Agent logged in to first AES and engaged into some operation or sitting idle and the first server went down.
1. So how the client will connect to second server. Do i've to write another bunch of code to get services again with second server? If yes, do I have to write this in "providerOutOfService" or "providerShutdown" overriden methods? Do i have to again add listeners(provider listener & call listener to terminal)?
2. How will I switch back to first server?
3. If the above operations are automatic and API will take care. How will I tell my program to use different TLINK credentials for both servers( tlink, username & password are different for both servers).

Looking forward for response.

Regards,
Md Arshad Ayub

Team, can anyone please reply on the post?

There are different types of HA. Have you read the high availability white paper available here?

JTAPI does not support high availability or failover of any type. The alternate TLINK feature is used only at startup to select which TLINK to connect to if one of the TLINKS configured is not available. Once the connection is made and the Provider created, JTAPI will not automatically failover to the second TLINK if the first one fails.

If an AES goes down, your application will receive a ProviderOutOfService and/or a ProviderShutdown event, if you have added a ProviderListener. When your application receives that event, it should create a new provider to the secondary AES. You will need to re-add any listeners from the first Provider.

Thanks for the response Shantanu, that means I've to re-initiate the entire process of creation-registration-callback method handling. But what will happen to the state of existing operation? Will it gets lost or do we have any class to sustain of the ongoing operation and patch it with the newly instantiated provider?

If by operation you mean any calls initiated by your application, they will not be affected by any drop in connectivity between AES and JTAPI. Any call listeners will need to be re-added, and they will get notofied of the existing calls.

I've read the AES HA white paper and scoured through this forum as well for related info.

The replies above state that if the initial AES that was used by the JTAPI app goes down, it is up to the JTAPI app to try and connect to another working AES , and then re-register all listeners (essentially, start from scratch!). This can be a tedious exercise, so I am looking for an alternate way.

1. It seems that the AES MPHA setup will provide a seamless failover experience to the JTAPI app (preserves state, and uses virtual IP). Also the White Paper clearly states under MPHA: "In the future, the TSAPI and JTAPI SDKs will re-establish these sockets upon a socket failure and preserve the previous session. It will also launch an audit and recover from the lost state in the AE Services VM.").
So would it be fair to say that with the MPHA setup specifically, the JTAPI app can receive full-HA service from AES??

2. The MPHA setup itself is a large task, and is not possible in Avaya Aura 7 (no System Platform available), or if the site has an all-VM setup. So if there are 2 independent AESs available, is the following possible/recommended:
the JTAPI app obtains a Provider from *both* AESs on startup, and all listeners are registered to both Providers. The JTAPI app will receive 2 events for every single logical event, and it needs to use only 1 stream (till it dies, at which point it uses the other one).

Any comments appreciated!

Hello,

1) If a JTAPI client socket drops, the JTAPI client will have to re-establish all listeners/registrations. That was true at the time the whitepaper came out, and is still true today. The sessions are not preserved.

2) It is possible to have a client application connect to two active AES servers. However, if the main concern is the amount of time it takes to reestablish all the listeners/registrations, then I would tend to believe the number of listeners/registrations may be significant enough that doubling the amount of CTI traffic may also be a concern. If the concern is regarding the events that may be missed between the failure & recovery; then there could still be events that occur between the period of time when the failure occurs and when the app detects or is notified of the failure on the first stream. If the app was simply ignoring/discarding the events on the second/"standby" stream, without processing the data, then those events are still essentially lost. Otherwise, there is more complexity because the app would have to process the events/data on both streams in order to potentially take action on an event that was received on a "standby" stream.

Regards.