I'm not sure what is the issue here, since your code is quite straight forward! One small note is that, according to the documentation, the "release" request takes no parameters, while you have specified an empty string parameter. I'm not convinced that it will make a difference, but it may be worth changing this.

Another known issue with session release is that there are actually two sessions to be considered - the Telephony Web Services (TWS) session and the Tomcat session. Although you may have successfully ended the TWS session, it is possible that the Tomcat session is still hanging around (and, possibly, holding on to the CM connection). The release of the Tomcat sessions is known to be a "lazy" mechanism. Essentially, Tomcat does not release a session immediately. Instead, the released session is put on an "expired" queue, and Tomcat gets around to releasing its expired sessions at a later. time

If it is possible, I recommend that, instead of releasing your TWS session (and then creating a new one) you try to re-use it. If this is not possible, you can try increasing the allowed number of concurrent connections to CM. Having more concurrent connections may allow Tomcat more time to clean up its expired sessions.

Additionally, I noticed, in your last post, that you tended to mis-spell "avaya-castor-override.jar". Please check the spelling in your classpath.

Speaking of mis-spellings, I see that I put one too many "a"s in "castor-1.0-xml.jar" in my post.

Sundarsanan,

Here is the order of the jar-files in the CLASSPATH used by the sample applications in the SDK:

activation.jar
mail.jar
api.jar
avaya-castor-override.jar
avaya-common.jar
caastor-1.0-xml.jar
client-media-stack.jar
commons-logging.jar
jakarta-regexp-1.1.jar
proxy.jar
xerces-J_2.9.1.jar

Please try this order and see if you still get the same error.

Click on the word "Next". Although it is not obvious, it is a button.

DMCC licenses are only required for client applications that want to register one or more devices with Communication Manger..

The Telephony Service API makes 3rd-party call requests, via TSAPI, to existing (already registered) devices. Hence, you need TSAPI basic licenses for this.

Unfortunately, you didn't list enough of the log to tell what the issue is. From the fragment that you gave, I would guess that there was a problem with the socket between your application and AES. However, I can't tell what the problem was.

No, I don't believe that the order of the jar-files in the classpath matters.

The "setCstaXSDEdition(int edition)" method in the Marshaller class was added by AES in order to differentiate between, and correctly handle, CSTA Edition-2 and Edition-3 namespaces in the XML.

The "org.exolab.castor.xml.Marshaller" class is included in the "castor-1.0-xml.jar", while the "com.avaya.mvcs.proxy.CstaMarshaller" class is included in the "proxy.jar". Both of these jar-files are included as part of the CMAPI SDK. Please ensure that these jar-files are included in your class-path.

No, it does not need to be the same. However, in the "change ip-services" screen on CM, on the last page, the "AE Services Server" should be the host-name of the AE Server (not the IP address), and the password should be the same as that entered on the AES' OAM Switch Connection screen.

The Switch Connection name on the AE Server can be any alphanumeric name (max 14 chars, I believe) that you want.

On the CM administration, enter the "change ip-services" screen, and go to the last page (normally p.3). Ensure that the name entered under "AE Services Server" is the host-name (not Switch Connection name) of your AE Server, and the password is the same as you entered for the "Edit Connnection" button on the AE Server "Switch Connections" page. Finally, on the CM screen, ensure that the "Enabled" field is set to "Y".

If everything checks out, restart the AE Server and wait a couple of minutes. If everything is correct, the AE Server "Switch Connections" page should indicate at least one active connection. and the CM "change ip-services" screen should indicate that the connection "Status" is "in use".

Another thing that you can check is the network interface being used by the AE Server to connect to CM.

On the OAM pages, go to "Networking" ->"AE Service IP". In the "Switch Connectivity" drop down box, ensure that the network interface (eth0, eth1 etc.) chosen is capable of finding a route to the CM IP address.

When you re-click the "Edit Connection" button, the switch password field is deliberately not shown (not even as asterisks). However, assuming that you entered the password previously, then the data has been stored in the database.

If the number of active connections is zero, then there is some disagreement between the AE Server configuration and the CM configuration. Check the settings on both the AE Server and CM to ensure that they agree.

In addition, if you make any changes to the "Switch Connections" web page, I suggest that you restart the AE Server from that "Maintenance" -> "Service Controller" page.

If the "Switch Conn. Summary" page doesn't list the Switch Connection, then you have not configured the connection correctly. Go to the OAM page: "Communication Manager Interface" -> "Switch Connections". Is your switch connection listed there? If so, does the Switch Connection have at least one active connection?

If there is at least one active connection for the Switch Connection, then it should appear on the "Switch Conn. Summary" page. If the Switch Connection has zero active connections, then you need to check your Switch Connection configuration.

To check your configuration, click on the "Edit Connection" button and check that the information specified is correct and matches the information specified on the switch itself.

Also click on the "Edit PE/CLAN IPs" button and check that you have entered a valid IP address. If you checked the "Processor Ethernet" box on the "Edit Connection" page, then this address should be the IP address of the Processor Ethernet connection of the switch. If you did not check the "Processor Ethernet" box, then this IP address should be the address of an active CLAN that is associated with the switch.

It sounds like there's a problem with your switch connection. On the AES OAM web-pages, if you click on "Status" - > "Status and Control" -> "Switch Conn. Summary", the "Conn. State" for the switch (to which you are trying to connect) should be set to "Talking". If it is not in the "Talking" state, then you have configured it incorrectly, and you need to check your settings. If the "Conn. State" is correctly set to "Talking", you should request Technical Support through the link on this DevConnect forum.