Please login or register to access secure site features.

Note: By continuing to use DevConnect Program Services you agree to our latest Registered Member Terms.

Sign in using DevConnect ID

Forgot password?

Trouble logging in?

Submit a ticket for Registration Support.

I have an SSO ID

sign in

Don't have a DevConnect or SSO ID ?

Create a DevConnect account or join the program.

register now
Messages posted by: MartinFlynn
Forum Index » Profile for MartinFlynn » Messages posted by MartinFlynn

Call Forward automatically redirects an incoming call before it is answered. There are several types (Always Forward, Forward if the phone does not answer, Forward if the phone is busy).

Call Transfer is where a user is in a call and adds another phone to the call while removing himself from the call.

You may find connectionAlerting() to be a better callback to use. You can see it being used in the AgentView sample application on the Devconnect website.

As far as I can see, JTAPI never sends those cause types. You will need to infer what is happening based on other information.

In order to see how JTAPI reacts to various call flows, I suggest you use the JTAPI Exerciser. You may also find the AgentView sample application on the Devconnect website to be helpful.

lastRedirectedAddress is populated if the call has been redirected - eg. the called phone has not answered and the call has gone to a coverage path. I think Call Forwarding would also cause this to be filled in.

Unfortunately, DMCC is not designed to be used in a browser. It requires a permanent TCP connection from the application to AE Services which is not normally possible in a web environment. The DMCC .Net ActiveX SDK does allow for this but only with a Microsoft browser.

To function with other browsers, I would suggest that you need to develop a server-based application which uses DMCC in the back-end to communicate with AE Services and has a REST/AJAX/... front-end which can communicate with a browser-based Javascript gui.

This information is not provided by JTAPI/TDAPI/DMCC. There is more information in the following thread:

An alternative way to get statistic information from Communication Manager, is to use DMCC and the VU Stat feature. There is more information in the thread:

You can also use the "list trace station NNNN" command on Communication Manager to see if a call has been initiated and some indication of why it failed.

Run the SAT command "list cti-link" on Communication Manager. Make sure that the CTI link to AE Services is of type "ADJ-IP". If it is not, you will need to remove it and re-create it with the correct type.

If that is not the problem, check page 4 of "display system-parameters customer-options". You may need to have "ASAI Link Core Capabilities? " and "ASAI Link Plus Capabilities?" set to Y. If these are set to N,
I think you can enable them using the Communication Manager web interface. Use the "Administration / Licensing / Feature Administration" menus.

If none of these is the cause, I suggest you check the DMCC traces on AE Services. This will show what requests the application is sending to AE Services and the results to them. Also, if the DMCC traces indicate a Call Control error, you should check the TSAPI traces on AE Services. There are instructions in:


The EndpointRegistration feature will tell you what terminal(s) are IN-SERVICE. The events from it will tell you when a terminal goes in/out of service.

The other events are Call Events. A listener, such as CallControlTerminalConnectionListener, will give you events as the call changes state.

Have a look at the "Endpoint Registration and Unregistration Events" section of the JTAPI programmers guide.

To the best of my knowledge, ActiveX will never be supported by non-Microsoft browsers. In fact, Avaya intend to remove the ActiveX option from DMCC shortly due to it's limited use and usefulness.

As for developing web-based clients for Aura in the future, I believe the correct system to use is the Avaya Client SDK. You can get more information on this at

The MakeCallResponse includes UCID as globallyUniqueCallLinkageID. Alternatively, UCID is included in several Call Control events (e.g. Delivered, Established) if you have a Call Control monitor on the station. You may need to do some configuration on Communication Manager in order to have UCID sent to AE Services. There is some information on this in the following FAQ

In order to know the current status of an Agent, you must perform GetAgentState.

I would suggest that you download the following from the Devconnect website:

1. "TSAPI for Avaya Communication Manager Programmer's Reference". DMCC Call Control features are provided by TSAPI and the TSAPI PG gives much more detail than the DMCC PG on these.

2. The DMCC .Net SDK. This includes the DMCC Dashboard which will allow you to test out the various DMCC features without having to write any code.

Yes, it is possible to use mutual authentication with TSAPI/JTAPI.

On AES web manager, click the Security -> Host AA -> Service Settings menu. Now, select "Authenticate Client Cert with Trusted Certs" for TSAPI. Click Apply a couple of times and restart TSAPI.

On the client side, you will need to import your ID cert into the Java keystore used by JTAPI. The approximate command for this is:
keytool -v -importkeystore -srckeystore "myIDCert.p12" -srcstoretype PKS12 -destkeystore "jtapiKeystore.jks" -destkeystoretype JKS

If your ID cert uses a different CA to AES, you will also need to import your CA cert into the AES "CA Trusted Certificates" list.

I think a file will override the logging settings in TSAPI.PRO.

If you add the following to your log4j properties file, it should stop JTAPI traces:

This is what I suspect is happening:

When the JTAPI client sends the connect request to AE Services, it starts a timer. It expects to receive some indication that the call is making progress within this time. Usually, the far-end network returns a Ringing/Alerting event almost immediately, which is sent back to the JTAPI client and it stops the timer.

Some networks do not send Ringing events, so the first event that the JTAPI Client receives is an Answered/Established event. This will not be generated until the call is answered.

If the call is not answered or the far-end user takes too long to answer, JTAPI Client will timeout and generate this error.

The length of the timer is controlled by the callCompletionTimeout parameter in your TSAPI.PRO file. You can change this to be longer.

There is more information on JTAPI properties in the JTAPI Programmers Guide.

Forum Index » Profile for MartinFlynn » Messages posted by MartinFlynn
Go to: