Hello,

We need to know how many DMCC client applications (e.g. call recorders) can be connected to a single AES Server in parallel.
In documentation, we've found a value for max. TSAPI service capacity, which is 2500 TLinks.
Is this the restriction that is also relevant for DMCC clients?

Regards,
Claus Suffel

Hi John,

Many thanks for your quick reply.

I will open the technical support request and provide the requested traces.

Yes, we are curently testing with the latest available DMCC Java SDK version 8.1.0.0.0.9.
In the past, we've never had any issues while connecting to older AES servers, even with the most current SDK versions.
Quite strange this time.

Am I right that the protocol differences between the used SDK and the connected AES server should be compensated automatically by the provided vXXToYYmapping.xml files?

Regards,
Claus

Hi John,

Please can you verify your comment.
Might there be something mixed up?

RegisterDevice was used in TerminalServices, which is deprecated now.
RegisterTerminalRequest is part of RegistrationServices, which should be used instead.

Regards,
Claus

Hello,

When trying to register a softphone extension with DMCC Java SDK 8.1, RegisterTerminalRequest fails with ServiceNotSupportedException:

2115 [SoftRegistrar] FINER com.avaya.mvap.svcproxy.ServiceProxy - request= session[null] com.avaya.csta.binding.RegisterTerminalRequest@604eef68
2117 [SoftRegistrar] WARNING com.avaya.mvcs.proxy.SDKBackwardCompatibilityImpl - Received an unsupported request
ch.ecma.csta.errors.ServiceNotSupportedException: LoginInfo.setMediaContent() or LoginInfo.setMediaTonesAnnc() is not supported by AEServer 8.0 or older server
at com.avaya.mvcs.proxy.SDKBackwardCompatibilityImpl.downgradeRequestFrom801To711(SDKBackwardCompatibilityImpl.java:148)
at com.avaya.mvcs.proxy.SDKBackwardCompatibilityImpl.downgradeRequest(SDKBackwardCompatibilityImpl.java:72)
at com.avaya.mvcs.proxy.XmlGatewayClient.handleAsynchronousRequest(XmlGatewayClient.java:296)
at com.avaya.mvcs.proxy.Pipeline.handleAsynchronousRequest(Pipeline.java:354)
at com.avaya.mvcs.proxy.ClientProxy.routeAsynchronousRequest(ClientProxy.java:757)
at com.avaya.mvap.svcproxy.ServiceProxy.marshallAsynchronousRequest(ServiceProxy.java:196)
at com.avaya.mvap.svcproxy.AsynchronousServicesProxy.sendRequest(AsynchronousServicesProxy.java:268)
at com.asc.cti.avaya.avayainterface.softphone.SoftphoneExtension.registerSoftphone(SoftphoneExtension.java:661)
at com.asc.cti.avaya.avayainterface.softphone.SoftphoneExtension.register(SoftphoneExtension.java:555)
at com.asc.cti.avaya.avayainterface.controller.softphone.SoftphoneController.startRegisterSoftphone(SoftphoneController.java:725)
at com.asc.cti.avaya.avayainterface.controller.softphone.SoftphoneController.access$8(SoftphoneController.java:695)
at com.asc.cti.avaya.avayainterface.controller.softphone.SoftphoneController$SoftRegistrar.run(SoftphoneController.java:637)

There is no call to LoginInfo.setMediaContent() or LoginInfo.setMediaTonesAnnc() in our code:

LoginInfo login = new LoginInfo();
login.setPassword("testpwd");
login.setSharedControl(Boolean.FALSE);
login.setMediaTonesAnnc(Boolean.FALSE);
login.setDependencyMode(DependencyMode.MAIN);
login.setMediaMode(MediaMode.CLIENT);

RegisterTerminalRequest regRequest = new RegisterTerminalRequest();
regRequest.setDevice(devID);
regRequest.setLoginInfo(login);
regRequest.setLocalMediaInfo(localMediaInfo);

services.getAsynchronousSvcs().sendRequest(regRequest, callBack);

All XML mapping files contained in SDK are all in place and available in Classpath.
AES Server version is 7.0.0.0.2.13.

Seems that RegisterTerminalRequest is already blocked by DMCC SDK.
WireShark trace does not show any transmission of this request to AES.

Regards,
Claus

Hi Martin,

It looks like SDK version 8.1 is not compatible with SLF4J anymore.
With version 7.0, we had no issues using SLF4J (together with log4j-over-slf4j) for logging of Avaya DMCC SDK and JTAPI SDK.

We now managed to avoid the IncompatibleClassChangeError issue described here by adding log4j.jar to our Classpath.
But this is not, what we really want, since we now have to deal with two different log files and configuration is required for two loggers.

The incompatibility with SLF4J / log4j-over-slf4j seems to be caused by the newly added avaya-commong-logging-0.0.4.jar.
These traces are showing the usage of some log4j classes that are not implemented by log4j-over-slf4j (or :

Without log4j.jar in Classpath:
[Loaded com.avaya.mvap.svcproxy.prov.BaseServiceProvider from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/proxy.jar]
[Loaded com.avaya.mvap.svcproxy.prov.RemoteServiceProvider from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/proxy.jar]
[Loaded com.avaya.proxy.binding.Resolver from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/avaya-common.jar]
[Loaded com.avaya.router.Router from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/proxy.jar]
[Loaded com.avaya.common.logging.Logger from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/avaya-common-logging-0.0.4.jar]
[Loaded org.apache.log4j.Priority from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/log4j-over-slf4j-1.7.30.jar]
[Loaded org.apache.log4j.Level from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/log4j-over-slf4j-1.7.30.jar]
[Loaded com.avaya.common.logging.Level from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/avaya-common-logging-0.0.4.jar]
[Loaded org.apache.log4j.spi.ErrorHandler from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/log4j-over-slf4j-1.7.30.jar]
Exception in thread "main" [Loaded java.lang.Throwable$PrintStreamOrWriter from C:\Program Files\Java\jdk1.8.0_152\jre\lib\rt.jar]
[Loaded java.lang.Throwable$WrappedPrintStream from C:\Program Files\Java\jdk1.8.0_152\jre\lib\rt.jar]
[Loaded java.util.IdentityHashMap$KeySet from C:\Program Files\Java\jdk1.8.0_152\jre\lib\rt.jar]
java.lang.IncompatibleClassChangeError: Implementing class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

Same section after adding log4j.jar to Classpath:
[Loaded com.avaya.mvap.svcproxy.prov.BaseServiceProvider from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/proxy.jar]
[Loaded com.avaya.mvap.svcproxy.prov.RemoteServiceProvider from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/proxy.jar]
[Loaded com.avaya.proxy.binding.Resolver from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/avaya-common.jar]
[Loaded com.avaya.router.Router from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/proxy.jar]
[Loaded com.avaya.common.logging.Logger from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/avaya-common-logging-0.0.4.jar]
[Loaded org.apache.log4j.Priority from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/log4j-1.2.17.jar]
[Loaded org.apache.log4j.Level from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/log4j-1.2.17.jar]
[Loaded com.avaya.common.logging.Level from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/avaya-common-logging-0.0.4.jar]
[Loaded org.apache.log4j.spi.OptionHandler from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/log4j-1.2.17.jar]
[Loaded org.apache.log4j.spi.ErrorHandler from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/log4j-1.2.17.jar]
[Loaded org.apache.log4j.spi.AppenderAttachable from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/log4j-1.2.17.jar]
[Loaded org.apache.log4j.Category from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/log4j-1.2.17.jar]
[Loaded org.apache.log4j.Logger from file:/C:/Eclipse%20Workspaces/NEO_60/avayatest/lib_8.1/log4j-1.2.17.jar]
[Loaded java.lang.management.ManagementFactory from C:\Program Files\Java\jdk1.8.0_152\jre\lib\rt.jar]

Is there a chance to make Avaya DMCC SDK compatible with SLF4J / log4j-over-slf4j again?
SLF4J is a widely used logging abstraction layer that usually seamlessly replaces log4j, as long as no special features are used.

Regards,
Claus

Hi Martin,

The library file avaya-common-logging-0.0.4.jar is already included in the Classpath.
We have removed it from the path in order to cross-check. The exception then changed to:

Exception in thread "TaskExecutor" java.lang.NoClassDefFoundError: com/avaya/common/logging/Logger
at com.avaya.mvap.svcproxy.prov.BaseServiceProvider.<clinit>(BaseServiceProvider.java:69)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getCmapiServiceProvider(ServiceProviderBuilder.java:192)
at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getServiceProviderType(ServiceProviderBuilder.java:180)
at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getServiceProviderImpl(ServiceProviderBuilder.java:112)
at com.avaya.cmapi.ServiceProvider.getCmapiServiceProvider(ServiceProvider.java:404)
at com.avaya.cmapi.ServiceProvider.getServiceProvider(ServiceProvider.java:390)
at com.asc.cti.avaya.avayainterface.connect.aes.AESConnector.establishAesConnection(AESConnector.java:378)
at com.asc.cti.avaya.avayainterface.connect.aes.AESConnector.connectToAes(AESConnector.java:303)
at com.asc.cti.avaya.avayainterface.connect.aes.AESConnector.access$600(AESConnector.java:73)
at com.asc.cti.avaya.avayainterface.connect.aes.AESConnector$TaskExecutor.run(AESConnector.java:1432)
Caused by: java.lang.ClassNotFoundException: com.avaya.common.logging.Logger
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 12 more

Is there anything else we can check?
Are there any known version incompatiblities with logging stuff like SLF4J or Log4j?

Regards,
Claus

Hello,

After upgrading DMCC Java SDK from V7.0 to V8.1, our DMCC application runs into an exception when trying to get a ServiceProvider instance:

serviceProvider = ServiceProvider.getServiceProvider(serviceProviderProperties);

throws:

Exception in thread "TaskExecutor" java.lang.IncompatibleClassChangeError: Implementing class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at com.avaya.mvap.svcproxy.prov.BaseServiceProvider.<clinit>(BaseServiceProvider.java:69)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getCmapiServiceProvider(ServiceProviderBuilder.java:192)
at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getServiceProviderType(ServiceProviderBuilder.java:180)
at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getServiceProviderImpl(ServiceProviderBuilder.java:112)
at com.avaya.cmapi.ServiceProvider.getCmapiServiceProvider(ServiceProvider.java:404)
at com.avaya.cmapi.ServiceProvider.getServiceProvider(ServiceProvider.java:390)

According to the debugger output, it looks like class "com.avaya.common.logging.FallbackErrorHandler" cannot be loaded correctly.

Is this a known issue and are there any hints how to avoid this failure?

Regards,
Claus

I'm not sure if receiving an InvalidObjectTypeException (EC: 18) automatilly implies that the cause is 58.
Do you have any documentation that describes those error codes and causes in detail?

Hi Martin,

It would be necessary to extract the cause value out of that exception, in order to compare it against the value '58'.
Do you have any idea how to do that with Java API?

Calling the getCause() method will deliver an object of type Throwable, but there is no explicit cause value number in it.

Regards,
Claus

We have registered an EndpointRegistrationStateListener for each monitored station.
But unfortunately, we do not receive any MonitorStop events in the case TSAPI link goes down.
We are using DMCC Java API 6.3.1.

When tracing the network communication with Wireshark, we can see that MonitorStop messages were sent from the AES to the client.

Regards,
Claus

Hello,

Our application registers some station monitors via DMCC Java API in order to receive CallControlEvents for those extensions.

After a restart of TSAPI Service on the AES Server, we do not get any further CallControlEvents.
But unfortunately, the application is not informed about the fact that the registered monitors are not operational anymore.

Is there a way to get informed about the TSAPI service outage?
How can we check, that the monitors are still operational?

Regards,
Claus

Hi John,

Are there any news regarding the capabilities ACE F/T offers for implementing a call recording solution that works similar to SSC or SO call recording as used in AES environments?

Regards
Claus

Hi Martin,

Is it mandatory to conference seperate softphones (e.g. via SSC) into the call when using Selective Listening Hold?

Or can this feature also be used in the case of Multiple registration (recorder is connected as a second instance to an existing extension)?

And how about the TSAPI Advanced license?
Is there just one license needed for enabling this feature in general? Or is it licensed per recorded party/ per softphone?

Regards,
Claus

Hello,

Is there any way to realize stereo call recording (seperate Rx and Tx streams) with DMCC?

Regards,
Claus

Hi John

Do you have any news regarding the schedule of implementing G722 support into the next version of Java DMCC API?

Are there plans for building CM hardware that will support G722 conferencing?

Regards
Claus