It looks like you are failing user authorization in the secure database. You mentioned that you have specified the user as a CTI user, but have you set up the Secure Database (SDB) to give the user the authority to use the device? Please read the documentation on how to set up the SDB, and how to associate the user with one or more devices.

Alternatively, if you don't require the security checks, you can disable the use off the SDB by DMCC from the OAM web-pages.

Hi Alessio,

An alarm is not posted for a failed DMCC registration due to no available licenses (or any other failure reason).

In general, alarms are not posted for any type of failed request from the client application. Instead, the client application is expected to note the reason for the failure in the response's return-code, and act appropriately.

I'll pass this information along to the folks responsible for CVLAN. Since I know that they'll ask this question, what version of AE Services and what version(s) of Communication Manager are you using?

Yes, the DMCC service should show ONLINE, since all of its functions are available. The lack of DMCC licenses in the WebLM license file does not affect DMCC's ability to provide service. Even for device registration, the user has the option to use IP_API_A licenses on Communication Manager,, instead of the DMCC_DMC licenses on WebLM.

Regarding the occasional drop of the connection to WebLM - the switch to using port 8443 usually corrects this; however,, we have seen a few other cases where it did not. The WebLM team are investigating this and hope to have a fix in the next release. I don't believe that this is a hardware issue - since the socket connection is internal to the AE Server, there really is no networking hardware involved. The good news is that, although it is somewhat annoying, this occasional drop of the socket is not service-affecting.

If there is a valid license installed on WebLM, then DMCC should be in NORMAL mode. It does not matter that there are no DMCC licenses available in the license file, since many DMCC functions do not require a license. In fact, only device registration uses DMCC licenses.

The occasional switch from NORMAL to UNKNOWN mode may be of concern, however. As you have noticed, this usually means that it has temporarily lost connection to the WebLM server.. If you are connecting to WebLM on port 443, you may be able to fix this issue by connecting on port 8443, instead. However, note that port 8443 is disabled (by default) and must be first enabled via the OAM.

I forgot to add that, if you change the "Switch Connectivity" setting, you will need to restart the DMCC service.

This type of problem can also occur if the AE Server is listening on the wrong ethernet interface. If the server has multiple interfaces, please go to the OAM (aka Management Console) web page: "Networking -> AE Service IP (Local IP)" and check that the "Switch Connectivity" is set to the correct interface (usually eth0, eth1 or ANY).

The fact that everything seems to work except that you don't get any RTP suggests that maybe there is a codec mismatch between you recorder app.and the other entities in the call. Check that all call participants can use G.723

Carlos,

You don't say what version of AE Services you are using. However, any version of R4.2 or later should work with G.723. The string to use for the codec is "g723". but note that G.723 codec can only be used for "client-media-mode". Since you are using "client-media-mode", I'm not sure what the problem is. Have you checked that the "ip-codec-set" on Communication Manager, that is being used for this extension, supports the G.723 codec?

Luis,

In the softphone.properties file, ensure that the trust-store location is specified as:

cmapi.trust_store_location=resources/avaya.jks

Note that the forward slash is used as the sub-directory separator. If you use the windows style backward slash, then you may need two of them:

cmapi.trust_store_location=resources\\avaya.jks

Also, check the OAM web pages. Click on "AE Services" -> "DMCC" -> "Media Properties". Ensure that the value specified for the "Player Directory" is the correct directory, containing the "greeting.wav" file (plus other ".wav" files used by the IVR application). In fact, if you want to play around with the sample apps., I recommend that you copy all of the ".wav" files from the default directory ("/cce/player") to "/tmp", and then set both the "Player Directory" and "Recorder Directory" to point to "/tmp". Note that some of the sample apps. (SimpleIVR included) require that the "Player Directory" and the "Recorder Directory" point to the same place.

Please check the AES OAM web pages and ensure that you have specified a Switch Connection for the Communication Manager, and that the connection is active. Furthermore, check that the CLAN IP address (that you are specifying for the registration) is included in the list of H.323 Gatekeepers for the Switch Connection.

As you mentioned, one of the advantages of using "attach" is that the authentication is done up-front, and is done only once. This is assuming that you use the returned "sessionID" in all subsequent requests. The re-use of the "sessionID" from the 'attach' assures that the subsequent requests use the existing credentials and session space (memory) already set up by the "attach".

If you do not use the "sessionID" returned by "attach", the result (as you have already stated) is that you will have to include the credentials with every request, and will be authenticated for every request. Furthermore, a new session will be created for every request, using up more server memory than is really necessary.

When a session is created, (irrespective of "how" it was created) it remains in existence until it is released, or until the "session timeout" expires. The "session timeout" is the amount of time that the session can remain idle before the session is automatically invalidated. The "session timeout" defaults to 30 mins for AES 5.2.2 and later (24 hours for earlier releases). Also note that, even once the session has timed-out and has been invalidated, the Apache Axis SessionHandler doesn't always clean-up the session (and free the memory) immediately. The SessionHandler waits until another request is received, before it checks for any expired previous sessions, and cleans them up

In conclusion, for all of the reasons mentioned above, it is recommended that you use the "attach" and "release" methods to create and, eventually, invalidate a session for your application.

Are you sure that the DMCC service is running? From the OAM web pages, check that the DMCC service is "ONLINE" and "Running". Also, port 4721 is normally disabled. If you enabled it, did you restart the DMCC service, afterward? Finally, if you can get access to the AE Server command line, check that the server is actually listening on ports 4721 & 4722.

By failing to copy the sessionID from one request to the next, you are creating an entirely new session for each request. This takes up extra memory and other resources used by Tomcat, and is therefore wasteful. Since the default session timeout is 30 minutes, these resources are held unnecessarily. For example, a "makecall" request typically takes a couple of seconds to complete, but the new session that you have created by invoking it (without copying the sessionID) will reserve the Tomcat resources for 30 minutes.