JTAPI Version: com.avaya:jtapi:8.1.3.6

We have implemented a listener that extends the CallControlTerminalConnectionListenerAdapter and register this at VDNs.

We have running the same application on multiple customer installations.
Since a few days/weeks on two installations, we can observe the behavior, that the Listener does stop to omit events.
The listener seems to run x days and is working fine, suddenly no more events are received.
There are no provider events (i. e. out of service) or error massages.

The customer with the errors has the following AES Version running: 10.8.200.91 (SW Version: 8.1.3.3.2.4-0)
Another customer with the errors has the following AES 8.1.3.8 with CM 8.1.3.3.0.890.27564.

Is there a way to check the listener if it still is receiving events or if the connection for this listener is expired?

Many applications use a query time of day method to ensure the overall connection to AES is operational. An application can query stations for feature state but that doesnt work for VDNs.
The application can use a station (a phantom X Port station is often used) to originate a call to the VDN and expect call events.

Listeners do not expire (there is no timeout). If eventing is stopping for a listener there is some other cause. Likely you want to enable TSAPI tracing on AE Services and then review the logs for cause when you stop seeing events for that particular listner being sent in the csta logs. If the AES continues to send events even though the application stopped receiving events, enable and review the JTAPI logs to see what may be occurring. There were some issues where some events began queuing in the JTAPI client which, to the best of my recollection, is fixed in the most recent JTAPI client (you dont mention its release - but it is available on the DevConnect portal, but there may be more, as yet, unnoticed cases thou.

Hello John,
we have downloaded the latest JTAPI Client as recommended by you.

Can you please verify the customer setup so that we are sure this is supported by the JTAPI Client 10.1.3.1.0.17

AES 8.1.3.8
CM 8.1.3.3.0.890.27564

Kind Regards, Dirk

The AES Overview document contains a listing of backwards compatibility of new clients against older AE Services releases.
https://documentation.avaya.com/en-US/bundle/AESOverviewAndSpec_R10.1/page/APIAndClientCompatibility.html
https://www.devconnectprogram.com/fileMedia/download/e5a3dbcf-d9bb-4d90-afc6-311494ab59b8 Page 78

Unfortunately it does not make explicit mention of JTAPI. I have reached back to the produt team for clarification, but expect to be told that the JTAPI 10.1.x clients are compatible with AE Services 8.1.x Just like with the TSAPI Clients. I can not find anything in the pbulic domain where that is made clear.

R&D confirms that there should have been a statement similar to the following in the 10.1 documentation.

JTAPI compatibility
AE Services Release 10.1.x JTAPI Service SDKs are backward compatible with the following AE Services releases:
• AE Services 8.1.x
• AE Services 10.1.x

They will work to get that added.

Thanks John!

Hello,

i have additional information about the CM and AEs Version, that are considered to produce the error regarding the missing vdn events.
CM 10.1.3.1.0.974.27937
AES-10.1.3.1.0.49-0

Another question regarding the vdn listener implementiation with AES Jtapi SDK.
How should the client handle the AES provider events "PROVIDER_OUT_OF_SERVICE" and shortly afterwards (within 5 seconds) followed by "PROVIDER_IN_SERVICE"?
Should the listeners be functional after such events or should the client remove the old listeners and register new listener on the Vdn?

Kind regards

You can observe AES's behavior in such a scenario by enabling TSAPI tracing on AES and then reviewing the g3trace file for the behavior in the window of time when such an event occurs. It is my expectation that the listeners will be removed if the AES is noticing the stream (session) to the application fail.