We have implemented the JTAPI event observers to build our softphone and facing a big problem as we would frequently not receive certain events and that would leave our softphone waiting for those events to happen and left hanging(it appears as if hanging to users).

Based on my analysis, the problem lies with the JTAPI not sending events to the call Observers, probably due to resource locking within their own code. Our softphone is based on event model where we register to receive different events via Avaya’s observer model and take our next action based on those events. The events should appear in certain order for softphone to make sense of what’s happening with the agent’s telephony activities.

In the different use cases Ianalysed, the error seems to be happening whenever transfers are involved. When the incoming call is transferred via conferencing, Avaya would not send events for the next or the following incoming call. This can be verified by monitoring the logs generated by JTAPI. Also I have noticed that Avaya will not destroy call observers post the call is disconnected and the observers list keeps building up. Note sure if this is causing the issue as this is something Avaya will have to investigate. Also it is quite evident from the logs, that there is a thread synchronization problem in JTAPI ‘TsapiCallMonitor’ object where a thread has locked the sync object and the others are waiting for the lock to be release to actually deliver events to the observers waiting for the events, which in our case is our softphone. Due to this lock scenario, the softphone keeps waiting for the right call event and appears frozen to our users.

After running JTAPI in trace level and having looked into JTAPI code available over GitHub, we have traced it back to the TsapiCallMonitor class making a lock on the syncObject and not releasing it.

Error scenario:
2018-08-24 15:05:29,315 [pool-1-thread-7] TRACE com.avaya.jtapi.tsapi.impl.monitor.TsapiCallMonitor - --> run[]: com.avaya.jtapi.tsapi.impl.monitor.TsapiCallMonitor@18adcc

Normal scenario:
2018-08-24 14:28:16,186 [pool-1-thread-14] TRACE com.avaya.jtapi.tsapi.impl.monitor.TsapiCallMonitor - --> run[]: com.avaya.jtapi.tsapi.impl.monitor.TsapiCallMonitor@8bbda5
2018-08-24 14:28:16,186 [pool-1-thread-14] DEBUG com.avaya.jtapi.tsapi.impl.monitor.TsapiCallMonitor - TP thread woke up: Locked callChangedEvent, attempting to Lock TsapiCallMonitor for CallObserver uk.co.rias.cti.agent.jtapi.RciAgentAddressCallObserver@1902c74
2018-08-24 14:28:16,186 [pool-1-thread-14] DEBUG com.avaya.jtapi.tsapi.impl.monitor.TsapiCallMonitor - TP thread Locked TsapiCallMonitor: removing events, itself for CallObserver uk.co.rias.cti.agent.jtapi.RciAgentAddressCallObserver@1902c74
2018-08-24 14:28:16,186 [pool-1-thread-14] DEBUG com.avaya.jtapi.tsapi.impl.monitor.TsapiCallMonitor - TP thread Unlocked TsapiCallMonitor: calling callChangedEvent, delivering events for CallObserver uk.co.rias.cti.agent.jtapi.RciAgentAddressCallObserver@1902c74
2018-08-24 14:28:16,186 [pool-1-thread-14] DEBUG com.avaya.jtapi.tsapi.impl.monitor.TsapiCallMonitor - TP thread returned from callChangedEvent, Unlocked callChangedEvent for CallObserver uk.co.rias.cti.agent.jtapi.RciAgentAddressCallObserver@1902c74
2018-08-24 14:28:16,186 [pool-1-thread-14] TRACE com.avaya.jtapi.tsapi.impl.monitor.TsapiCallMonitor - <-- run[]: com.avaya.jtapi.tsapi.impl.monitor.TsapiCallMonitor@8bbda5


Please can this be looked into and let me know if some more log files will be handy!

Regards,
Gurpreet

Hi Gurpreet,

Firstly, the Observer classes have been deprecated for approximately 10 years. Instead, you should be using the Listener classes.

I have come across cases in the past where the JTAPI event delivery thread has become blocked. This has always been due to an error in the application whereby it performs event processing using the JTAPI event thread. The callback function that receives an event should:

1. Release the JTAPI event thread ASAP. It should process the event using its own worker thread.
2. Never make any API calls using the JTAPI event thread.

There is a sample JTAPI application on the Devconnect website called AgentView which uses an internal queue and worker thread to process events. I suggest you take a look at it.

Martin