MR for this is AES-33461

Sorry, I was away for a few days.

I am able to reproduce your issue so it looks like an incompatibility has crept in between DMCC 10.0.1 and AES 8.x. You will need to stay with DMCC 8.x.

I will open a bug report for this but it will be some time before this would be resolved, it at all.

Martin

I don't see that problem with DMCC 10.1.0.2 and AES 10.1.2. There can be a problem when DMCC & AES communicate using a version of the DMCC protocol that is older than the DMCC client. Normally the problem is that the application classpath does not including the XML files from the "mapping" folder in the lib but, occasionally, there can be a bug.

What version of AES are you using and, most important, what version of the DMCC protocol has been negotiated when you started the Application Session? You will need to check the StartApplicationSessionResponse to see this. The easiest way is to check the DMCC traces on AES.

Martin

Make sure the WTI service is in the "Running" state. Use the AES web interface, menu Maintenance -> Service Controller. If WTI is stopped, start it. If it is "Ready" (I think), restart it.

Martin

For the trace issue, make sure you are using the correct version of the log4j libraries for the version of the DMCC client you are using. Avaya changed to log4j v2 some time ago. It is possible that you are still using the old version.

Martin

Make sure you are trying to connect to port 4722 and not 4721.

Also, use Wireshark to check the handshaking as the TLS connection is setup. If there is a certificate error, you should be able to get an idea as to what it is.

Martin

DMCC events do not include the device name. However, if you have a Device ID for the device (Station, VDN or Hunt Group) you can use GetPhysicalDeviceName to get the name that is configured for the device on Communication Manager.

Martin

I notice the title of the thread is GetDeviceId() but the description seems to be that you have a problem with RegisterTerminal. Which, of these is causing a problem?

BTW, that error may indicate that the one of the TSAPI service, TSAPI link to CM or Switch Connection to CM is down. For example, see the following thread:
https://www.devconnectprogram.com/forums/posts/list/3269.page#p51032

Martin

WTI piggy-backs on DMCC and DMCC Call Control is basically a wrapper for TSAPI. So, for anyone working with WTI, the following docuemnts and tools will be invaluable:

Documents:
1. Avaya Aura® Application Enablement Services Device, Media and Call Control .NET API Programmer’s Guide

There is also an XML and Java guide which give the same information.

2. Avaya Aura® Application Enablement Services TSAPI for Avaya Communication Manager Programmer’s Reference

This gives the most information for Call Control features. It is absolutely necessary for understanding that are valid values for paramaters, how requests interact with CM features and the meaning of many of the error codes.

You can download all of these documents from the Devconnect website.

Tracing:
Enable DMCC and TSAPI traces on AES. From the AES Web Manager use the "Status -> Log Manager -> Trace Logging Levels" menu to get to the Trace Logging Levels page. Set "TSAPI Service" to "Everything on". Set all DMCC levels to "FINEST".

AES traces are stored in /var/log/avaya/aes/. WTI traces are telrestsvc.log and DMCC traces are dmcc-trace.log (they both rollover). TSAPI traces are in the TSAPI folder. csta_trace.out shows messages between TSAPI & DMCC. g3trace.out shows the messages to/from CM.

Test Tool:
I would encourage you to download the DMCC .Net SDK from the Devconnect website. This includes the DMCC Dashboard which allows you to easily send & receive DMCC messages to/from AES. This bi-passes WTI and auto-generates the DMCC XML messages. The data in these messages matches almost exactly the data in the WTI JSON messages so you can easily see what data AES expects and what data you can expect to receive.

Martin

The dashboard is tricky to figure out at first but it does have a certain logic to it.

It is possible to get the media from single parties in a call using the Custom Media Streams feature. This will work for all three types of DMCC recorder (Multiple Registration, Single-step Conference or Service Observer). There is more information in the "Custom Media Streams" section of the programmers guide. There are also a few threads in the DMCC forum about it.

Martin

You need to have already started a session management monitor before using Device ID List or Get Monitor List. They are very specialized API calls and I am guessing they do not do what you think they do. I suggest you read the Programmers Guide about them.

Martin

You will be able to do the same things with DMCC as you can do with JTAPI now.

There are a couple of possible reasons why you could be blocked from connecting:

1. Make sure that the Requested Protocol version is not too big for your AES. For example, if the AES is 8.1.3, you will need to set the Protocol version to 8.1.3 or lower.

2. By default, port 4721 is blocked on AES. Login to the AES web interface aid use the "Networking -> Ports" menu. If port 4721 is disabled, enable it and follow the instructions - you will need to restart the DMCC service.

Martin

This is a known issue. Somewhere between 11.0.5 and 11.0.11, the Java compiler stopped supporting this entry in the Manifest.

The simplest workaround is to unzip the proxy jar file and include the class files in your classpath directly.

Martin

You will not find JTAPI very useful for a recorder. Instead, you should use DMCC. This will allow you to register recording devices and ask for media from a call to be echoed to an IP address & port where you can access it. You can get more information on DMCC and download the SDKs from
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/releases/10_2/index.gsp#download-6

Martin