Could not meet post conditions of connect()

[Zygmuntix]

I am trying to solve the problem that our customer have. They have many Cisco UCM agents using Cisco Jabber.

I use JTapi to connect to Cisco UCM.

Then I call this code:

Call call  =  provider.createCall();
Connection[] connections = call.connect(terminal,  this.address,  dest);

Unfortunately in case of small number of users - they have the problem. The calls are made about 30 seconds after this code is called. I would like them to be able to make the calls instantly or at least in few seconds. How can I solve this problem?

I also see some exceptions (they appear randomly, sometimes they appear, sometimes no, but it is very visible when using so many agents) in the logs:

connect:

com.cisco.jtapi.PlatformExceptionImpl: Timeout - Could not meet post conditions of connect()
at com.cisco.jtapi.CallImpl.connect(CTQF) ~[tcc-5.2.0-fat.jar:na]
at com.cisco.jtapi.CallImpl.connect(CTQF) ~[tcc-5.2.0-fat.jar:na]

in case of hangup:

com.cisco.jtapi.InvalidStateExceptionImpl: Did not meet pre-conditions -- call must be ACTIVE and at least one TerminalConnection must be Active
at com.cisco.jtapi.CallImpl.drop(CTQF) ~[tcc-5.2.0-fat.jar:na]

Second, very connected question:

Is it possible to make asynchronous calls using Cisco UCM (non-blocking)? I do not see any method like:

call.connectasync()

[dstaudt]

call.connect() should definitely not take seconds, especially ~30 seconds - something seems to be pretty awry.  AFAIK it should block only while a message is sent over the wire to CUCM and received back, CUCM processing the call almost instantaneously.

If you haven't seen this set of samples, there is a basic make-call sample available: https://github.com/CiscoDevNet/jtapi-samples

The errors mentioned seem to indicate that requests are timing out (I think JTAPI's default CTI timeout is 15 sec).  I would suggest checking that the application can reach the CTI Manager host with a reasonable ping (no loss/retries/DNS timeouts etc.), that the server/OS has nominal performance, and then take a close look at the application's threading model, etc.

One general design consideration is to avoid doing JTAPI library stuff (besides static object reads) from within Observer callbacks.  Observer handlers should simply grab the message contents and place them into an application-internal queue/state-machine for processing, then return.

[Zygmuntix]

I analysed the problem and we had ~30 seconds of waiting until making the call because there were many requests sent to our application to make the call. So many that it was stack (many requests were waiting to be done - user clicked the button to make the call but many other users at the similar time clicked this button so many events to make the call were created and then processed one by one (each event had to wait).

Anyway there is still the problem with waiting 3-4 seconds after making the call, jtapi code is blocking, so we cannot make many calls at the same time. And there is still this problem with com.cisco.jtapi.PlatformExceptionImpl: Timeout - Could not meet post conditions of connect() but it looks like it happens after making the call - so there are still some problems.

I saw in some Cisco sample code (another then the one you posted) that the new Thread is created each time when making new Call:

Cisco UCM code sample 

Please tell me - is Provider object Thread-safe?

[upchaurasia · Accepted solution]

Hi,

As .connect is synchronous so you should move your make call function in new thread and also event should be process in thread pool.

Thanks & Regards,

Umesh

[Zygmuntix]

 upchaurasia was right, to resolve the issue I have to create a separate thread for running each make call so that the code will not be blocking. I got the answer from Cisco team from DevNet - Provider object is Thread-safe.