JTAPI needs a configuration file called TSAPI.PRO in the classpath. Such a configuration file needs entry for TelephonyServer ip address. Does classpath of your application has it ?

You can find a sample TSAPI.PRO file in the JTAPI installation.

Yes, TSAPI.PRO is a configuration file that JTAPI sdk requires.
So you would need it in the classpath of your java application.

Since you are using 4.2 release, you could refer the AE Services TSAPI,JTAPI,CVLAN Client and SDK installation guide.

Please refer AES Administration and Maintenance Guide for details. Look for a section called "OAM User Management Administration" which explains the process to add a cti user. You will also have to refer the Security Database section to decide the kind of privileges you would like to give the user you created using the User Management link.

You can create an object that implements the callObserver interface and provide that object as a parameter to this api.

AddPredictiveCallObserver api is avaya's extension to the JTAPI 1.4 specs. With JTAPI release 5.2.3 and 6.1 , corresponding AddPredicitveListener api would be available.

I am assuming you are talking about predicitve call scenario where you want events as soon as the vdn starts the process of placing the call.

Consider adding a predictive call observer to the vdn via the api addPredictiveCallObserver exposed via the interface LucentV7ACDManagerAddress.

As mentioned in my post below, JTAPI supports listeners with 5.2 release onwards.

You seem to be using JTAPI 4.2 and so if you go ahead and add a callListener, your code will be presented with "MethodNotSupportedException"

Please note that listeners are supported with JTAPI 5.2 release onwards.

you could use the api getAddress exposed on the provider interface and pass the required extension.

I would recommend you to go through java docs for questions related to apis.

strings like T296#2 represent off switch parties involved in the call. This is the format that is used to represent these off switch parties.

I can see a warning message in the logs posted below which makes me ask you the question : What is the version of AES being used ?

Please refer the java docs.

This field is populated only when both the VDN and the agent station are monitored.

Calls get queued at the skill. Since you are not getting CSTAQueuedEvent in the logs , I suspect that call are not getting queued at the skill at all. Have you checked your CM setup and verified that calls are getting queued ?

1: To implement your idea of performance improvement , you could use an api getLoggedOnAgents() on the ACD address in question. This api will return you an array of agent objects. Each of these agent objects will provide you the terminal through which it has logged into the ACD.

2: You could add an ACDAddressObserver to the ACD . This observer will provide you events like ACDAddrLoggedOnEv when the agent logins into the ACD. This event holds the information like the agent which logged in. You could also extract the terminal through which the agent logged in by invoking the api agent.getAgentTerminal().

If the calls are really getting queued at the huntgroup in question then you should see the CSTAQueuedEvent in the logs. This CSTAQueuedEvent gets converted to JTAPI event connectionQueued.

TSAPI, JTAPI, and DMCC applications using a single AES server should be able to create an unlimited number of CallObservers/listeners for the same VDN. This is because TSAPI will simply distribute the events from the single ASAI Event Notification to each CallObserver.

I would recommend you to turn on the logging and check the logs to see whether you are receiving CSTAQueuedEvent for the huntgroup in question.

To turn the logging on , you should set debugLevel=6 and set altTraceFile=some location on file system