Hi guys,

we have a custom CTI application (JTAPI client) that runs along AIC. It can be requested to monitor certain calls by the agents on demand. The code invokes addCallListener() on the corresponding Call object itself and processes further based on the received call events. The CTI client application runs fine for any inbound scenarios (and also for outgoing calls if those were not initiated from AIC Web Client, but eg.: from the agent's softphone directly). In case of an outbound call made from the AIC Web Client attaching a call listener on the Call object does not fail, but results:
- com.avaya.jtapi.tsapi.TsapiResourceUnavailableException: CSTA Error: 44 being logged in JTAPI log (Note the exception is caught and logged by JTAPI, but not thrown further.)
- no call events are being received by the attached call listener.

Any clue why do we fail to monitor the call in this particular scenario? Is it a known interoperability issue with AIC?

ecsjtapia 7.1.0.8
AES: 7.1.3.3
CM: 7.1.3.0.0-FP3
AIC: 7.3.5

Thanks, Sandor

Hi Sandor,

Communication Manager has a concept called "Adjunct Control Associations per Call" - I'll call it "Call Association". There can be a maximum of one of these associations per call. Basically, if a CTI application monitors a call or makes a call, it must first grab the Call Association. The Call Association is held until the call ends.

Interaction Center uses the CVLAN API to communicate with Communication Manager (via AE Services). So, when you use the AIC client to make a call, it takes this association and holds it for the duration of the call. When your application tries to monitor the call, it cannot get the association and the attempt fails. This is a limitation of the system.

To overcome this limitation, you can change your application to monitor the agent's phone at startup. You will get the same events (or very similar) and will not need the Call Association.

Martin

Thanks Martin! Monitoring the agent's Address instead of the Call directly seems to be a viable workaround for this indeed. We'll need to change our design to accommodate that, but it should be working. Let me still make two remarks on this issue (and ask your feedback if you agree or not):
- JTAPI library currently hides this error. Call.addCallListener() does not propagate this exception, there is only an error level log message in the JTAPI log, but the client code cannot differentiate successful and failing scenarios in this case.
- For a client that is only interested in receiving call events (and does not do call control) this necessity of obtaining the "Call Association" on call.addCallListener() seems to be an unnecessary restriction.

Again, thanks for the support!

Regards, Sandor