The error message indicates that you attempted to use an IP_API_A license on the CM for the registration, but none were available. Do you have available IP_API_A licenses on the switch?

Yes, the bug fix concerning AES licensing when connected to CM 5.2 is in AES 4.2.2.

You noted earlier that your DeviceID is "1143:FAREHAM:10.15.11.232:0". Please go to the OAM web pages for AES and check that the name of the "Switch Connection" is "FAREHAM" and that the IP address: 10.15.11.232 is included in the lists of "CLAN IP Addresses" and ""H323 Gatekeeper IP Addresses" for that Switch Connection. Also note that, prior to AES 4.2.2, the "Switch Connection" name is case sensitive.

As I mentioned in my reply of Jun 30 2008, it is necessary to ensure that you have provisioned the correct ethernet interface to the switch. Check the AE Server Administration web-pages. Go to "CTI OAM Administration" -> "Administration" -> "Network Configuration" -> "Local IP". Ensure that, for the "Switch Connectivity" field, you have selected the correct ethernet interface for the subnet containing your switch.

Kliment,

FYI - I noticed that you mentioned that your application is using JDK6. While this should not be a problem in most cases, I just want to mention that we recommend JDK5 for AES R4.x applications, since that is the basis for our own testing.

Regards.

Kliment,

Thank you or your informative reply. You may be correct in your assumption that it is a bug in the JDK6 implementation. We would have to do some more load testing to be able to make that determination. I am well aware that the JVM TimerTask implementation has its limitations, and of the possibility of the Timer threads backing up. Unfortunately, at the moment, there is no simple way to turn-off the transmit side of the RTP, while leaving the receive side fully functional. However, an implementation of this should be quite simple and I will certainly add it to our list of customer-requested features.

FYI - the IncompatibleClassChangeError thrown by line 272 is a simple read() method call of the audio MediaReadableChannel. I'll suggest adding code to protect against this kind of error in the future.

Kliment,

No, we have not seen these kinds of errors in our testing. However, neither have we tested with the kind of load that you are generating. The original purpose of the client-media-stack was to bundle it with our sample code - as an aid developers in writing simple applications that requiredclient-media. We envisioned such applications as handling just a few RTP streams - not hundreds. We have found that most of our independent vendors requiring this kind of functionality already have their own media stacks, for their production environments.

The IncompatibleClassChangeError is very strange - as if your media source or media sink were being changed while the media session is established. Is this something that your applicaation might be doing?

Unfortunately, the Memory Access Violation (0xc0000005) can have a myriad of causes - especially if you are running in a Windows environment. My only suggestions for this one are to check that you are using JDK 1.5.0_10, and to increase the amount of memory allocated to the JVM.

This error message indicates that the asailink process on the AES died, at some point, without releasing its license. When the process restarted, it was allocated a temporary license, while an attempt is made to recover the original license. Also, a 30-day timer is started. If the license is not recovered within the 30 days, the asailink process will be restarted.

Other than a brief interruption when the asailink process is restarted, this error shouldn't adversely affect the performance of the AES, and should correct itself at the end of the 30 days.

However, the fact that the original license couldn't be recovered ina timely manner may be an indication of another problem. I suggest that you contact your Avaya representative to determine if this may be an issue.

Steven,

Did you restart the service after re-applying the license? If this does not fix the problem, then we need to know which service is complaining and what is the exact error message?

Kliment,

Somehow part of my message got lost. To continue:

Once your application has read the local_udpport_min & local_udpport_max from the user-configuration.properties, it needs to pass them on to the MediaFactory. For example:

private String UDP_MIN = "com.avaya.mvcs.media.MediaManagerServices.local_udpport_min";
UDP_MAX = "com.avaya.mvcs.media.MediaManagerServices.local_udpport_max";
Properties mediaProps = new Properties();
mediaProps.setProperty(UDP_MIN, local_udpport_min);
mediaProps.setProperty(UDP_MAX, local_udpport_max);
MediaFactory factory = MediaFactory.createFactory(mediaProps);

Kliment,

The default range for RTP & RTCP ports in AES R4.2.1 and earlier is 5000-5300. Since 2 ports are required per call, this is where the 150 call limit comes from.

To change the range of ports used for RTP/RTCP you need to specify the following in the application's "user-configuration.properties" file in the "resources" directory:

com.avaya.mvcs.media.MediaManagerServices.local_udpport_min=40000
com.avaya.mvcs.media.MediaManagerServices.local_udpport_max=47999

or similar (depending on the range needed).

Rajeev,

When Communication Manager sets up a call between two endpoints, it attempts to find a common set of media capabilities (codec, encryption etc.) between the two. Depending on the capabilities specified by each endpoint at registration, plus the capabilities in the ip-network regions, Communication Manager may, or may not, be able to find a common set. If it cannot find a common set (such as in your case where one endpoint uses G.711 and the other uses G.729), then CM must play "man-in-the-middle" and trans-code the audio between the two. Thus, in this case, the G.711 endpoint talks to CM in G.711 and CM talks back in G.711, and so the Rx and Tx parameters are the same, as far as the G.711 endpoint is concerned. Similarly, the G.729 endpoint talks to CM in G.729 and CM talks back in G.729 - and again the Rx and TX parameters are the same, as far as the G.729 endpoint is concerned.

Setting the protocol version = "4.2" will not work. The actual string is the one used by the Dashboard (i.e. set the protocol string to "http://www.ecma-international.org/standards/ecma-323/csta/ed3/priv3").

Are you using your own application or just the Dashboard? What happens if you do not specify a protocol version and let it default? Finally, if you are just using the Dashboard application, what version of the Dashboard are you using?

Judging by the response that you got, it was the AE Server that rejected the protocol version. If you are sure that the AE Server is R4.2, you should contact your Avaya service representative.