Hello All
We started seeing errors on both TSAPI trace and aesconnector traces after both OD and AES have been upgraded. The new versions are:
OD: 8.1
AES Connector: 08.10.06.01
AES: 8.1.3.6.0.8-0

We have OD applications running on multiple tomcat instances which are integrated with AES through the AES connector. Since the upgrade we see that the open streams on AES side keep increasing. And after a threshold of approx 2500, the calls get disconencted and we begin to see CSTA Error: 41 errors in AES connector traces which results in AES connector not be able to add observers on IVR extensions.
restarting AES conenctor decreases the number of streams on AES but after a while they start increasing again. The number of open streams on the old systems was around 20.

The following errors are seen in tsapi traces frequently:
2022-12-26 09:26:41,845 [DistributeCSTAEvent] INFO TSEventHandler - Handling CSTA_HELD for TSProvider[#296]@949f8ce
2022-12-26 09:26:41,845 [DistributeCSTAEvent] ERROR TSEventHandler - Event Distributor Exception - shutting down provider TSProvider[#296]@949f8ce
2022-12-26 09:26:41,845 [DistributeCSTAEvent] ERROR TSEventHandler -
java.lang.NullPointerException
2022-12-26 09:26:41,845 [DistributeCSTAEvent] INFO TSProviderImpl - TSProvider.shutdown - attempting shutdown
2022-12-26 09:26:41,845 [DistributeCSTAEvent] INFO TSProviderImpl - TSProvider.shutdown - Starting

And these errors are seen frequently in AES connector traces:
24/12/2022 16:58:04 DEBUG - ProviderObserver.providerChangedEvent: got provider shutdown event:112

24/12/2022 19:38:14 DEBUG - shutdownProvider:Problem shutting down: XXXXX will continue (XXXX is the IVR extension here)

I am attaching sapmle tsapi trace and aesconnector trace.
Can you please explain the reason for these errors and how to solve them?

Regards

Hello,
yes the war file was exported from OD for servlet container: tomcat8.
Our OD version 7.1.
Today I imported the same application on OD 7.2 and exported the war from OD 7.2. I deployed it on Tomcat 8.5.64 and it worked.
So my question is: Isn't OD 7.1 supported on Tomcat 8.5.64? I did not see such a note in DevGuide, it says OD71 is supported on Tomcat 8.x.

Regards

Hello
We we are upgrading our tomcat from 7.0.77 to 8.5.64.
We set up tomcat 8.5.64, added the jar files exported from OD 7.1.0 and did necessary configurations in the runtimeconfig application.
Bu we find that nested module calls fail in 3rd level.
For example: we have the main app AnaModul1 calling, AltModul1. Then AltModul1 calls AltModul3. AltModul1 call is successful but AltModul3 call fails. the call disconnects without any error message in trace file. If I call AltModul3 directly from AnaModul1, then it is successful.
We don't have this problem in 7.0.77.
Sample trace is attached.
Do you have any idea about the cause of this?

Thank you,regards

Hello
We have the following system:
WebSphere Platform 9.0.5.4
Java version = 1.8.0_261
Java Runtime Version = 8.0.6.16
Orchestration Designer 07.20.09.04
WebLM v7.0

On two of our websphere servers, we get the" License URL is not valid, or server is not up" issue while using https. We don't have this issue on the other websphere servers with the same websphere, java and OD version. http works fine in the problematic servers.
We have exported the certificate from the weblm page and installed it on problematic webspheres using IBM websphere console but it did not help.
Can you suggest any other thing to check? I found lots of threads regarding the weblm issue on tomcats but not for websphere.
Thank you

Hello
So do you say it is normal that these runtimeconfig entries get mixed up after restart or that this should not happen?

Regards and thanks

Hello
We have one weblogic server hosting an IVR application (IVR A) on 4 instances and another IVR application (IVR B) on 1 instance. These IVR applications require different runtimeconfig entries. So we go to the runtmeconfig URL on each instance and enter the required entries for the IVR application running on that instance. Evereything is fine so far.

But after instances or whole cluster is restarted, the runtimeconfig entries get lost or mixed up for the instances (entries for IVR B are shown on runtimeconfig on the instance where IVR A is hosted). Because of this we have to check each and every runtimeconfig and fix the entries if needed after every restart. This is very time consuming.
Why is this happening and is there a way to avoid this?

regards and thanks

Hello
I was able to get the UCID of the dialed call by doing the consultation call explicitly, meaning 1st hold the call, dial to the destination and then transfer.
for your information,
Thanks

Hello
We use Cosultation Call feature of AES conenctor to transfer Call from IVR to agent.
We are w?ndering Is there a way to get the UCID of the dailed call that is generated behind scenes of Consultation Call?
This info is automatically shown in IVR trace as following:

CallInfo.doGetCallInfo: Populating dialed call info variable values...
CTICommand.setCallInfoVariableValues: Call ID 4561
CTICommand.setCallInfoVariableValues: Calling # (ANI) 7411
CTICommand.setCallInfoVariableValues: Called # (DNIS) 7631
CTICommand.setCallInfoVariableValues: Ext 7411
CTICommand.setCallInfoVariableValues: UCID 00001045611590999464
CTICommand.setCallInfoVariableValues: UUI POPUP=SessionID:AVEPM01-2020153081709-2*IN:-|TN:905497438370|IVR:VEDAS
CTICommand.setCallInfoVariableValues: State queued

We used a Callinfo data node after the consultation call node to get the UCID but it returns the call that has been held before Dial.
Any ideas would be very helpful

Thank you

Hello
We are moving our OD 7.2 projects to weblogic and we find that no trace.log files are generated for icconnector application.
We had also found that stuck threads were forming in weblogic because of the at com.avaya.sce.runtimecommon.SCESession.createDirectoryStructure(SCESession.java:2543) error.
We checked the former thread https://www.devconnectprogram.com/forums/posts/list/19318.page

and created the data/temp and data/log files under the application directory for icconenctor.

Bus still te stuck threads are being generated and no trace.log is written under data/temp.

The iclog4j.properties which is under the WEB-INF directory is as following:

#log4j.rootLogger=error, stdout

log4j.logger.IC.TraceWriter.ic= debug, Tic
log4j.logger.IC.ReportWriter.ic= debug, Ric

# Console
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{dd/MM/yyyy HH:mm:ss:SSS} %5p - %m%n

# Report File.
log4j.appender.Ric=org.apache.log4j.DailyRollingFileAppender
log4j.appender.Ric.File=${ic.apphome}/report.log
log4j.appender.Ric.DatePattern='.'yyyy-MM-dd
log4j.appender.Ric.layout=org.apache.log4j.PatternLayout
log4j.appender.Ric.layout.ConversionPattern=%d{dd/MM/yyyy HH:mm:ss:SSS} %5p - %m%n

# Trace File.
log4j.appender.Tic=org.apache.log4j.DailyRollingFileAppender
log4j.appender.Tic.File=${ic.apphome}/trace.log
log4j.appender.Tic.DatePattern='.'yyyy-MM-dd
log4j.appender.Tic.layout=org.apache.log4j.PatternLayout
log4j.appender.Tic.layout.ConversionPattern=%d{dd/MM/yyyy HH:mm:ss:SSS} %5p - %m%n


Can you please help?

Regards

Hello
We set up a new webpshere instance hosting aesconenctor. We did all necessary configurations in runtimeconfig and the tsapi.pro file.
The provider name in runtimeconfig AES configuration is correct (AVAYA#CLAN#CSTA#ISAESTSAPI2) and the contents of tsapi.pro is as following:
#Sun Nov 06 00:33:04 EST 2005
debugLevel=0
10.178.194.181=450
altTraceFile=tsapi_trace.txt

I also checked network connectivity between the webpshere machine and 10.178.194.181 port:450. No issues there either.

When we start aesconnector, we get the following messages repeatedly:

06/04/2020 17:04:08:696 DEBUG - CTIConnectorManager.getConnectionString: No entry for TServer in configuration file
06/04/2020 17:04:08:696 DEBUG - CTIConnectorManager.initProvider: Look for TServer config in DD application configuration (new method to 4.0)
06/04/2020 17:04:08:701 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: getting provider:AVAYA#CLAN#CSTA#ISAESTSAPI2
06/04/2020 17:04:09:721 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider obtained
06/04/2020 17:04:09:721 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: give provider cycles:40 of delay:100ms
06/04/2020 17:04:09:721 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:09:821 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:09:921 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:10:021 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:10:122 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:10:222 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:10:322 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:10:422 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:10:522 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:10:622 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:10:723 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:10:823 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:10:923 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:11:023 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:11:123 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:11:223 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:11:323 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:11:423 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:11:524 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:11:624 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:11:724 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:11:824 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:11:924 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:12:024 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:12:124 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:12:225 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
06/04/2020 17:04:12:325 DEBUG - CTIConnectorManager.ConfigureFromConfigurationFile: provider is not in service -- STATE: 1, give small delay
.
.
.


What could be the reason for this?
Thanks a lot

Hello
We developed an outbound IVR application which is triggered by a custom application using EP web services.
The outbound IVR application is IC enabled and makes a newcall request at at beginning and successfully get and EDU ID from IC. The IVR application sets customer data in EDU and the transfers the call to agent. It uses IC transfer for this and IC transfer fails. IC transfer triggers HttpVox.transfer. In Httpvox logs we see "incorrect extension state" error and that's why IC transfer fails.

We notice that, EP makes the state of IVR extension "processing" on which the outbound IVR application is running, which is different from a normal inbound call.

We don't have this problem for inbound calls.
Do you have any idea why this is happening?

Thank you

Hello
Customer detected our Tomcat server is using TLS 1.0 to connect to the customer's crm webservices. We are using the tomcat that comes with EPMS version 7.0.0. The tomcat version is 6.0.37. The java version on the tomcat server is 1.7.0_25. The scert_common version for OD is 07.01.08.04.

Customer wants us to upgrade to TLS 1.2 for security purposes. Can you please specify how to do this? Are the above mentioned versions suitable for this upgrade or do we have to a platform upgrade?

Regards

Hello
Actually there are two tomcat versions running with different java versions on that same machine.
The tomcat I am running this runtimeconfig on, is using Java 7. No problems with that.
The other tomcat uses java 6 which is the default java on that machine. (java -version response)
May the runtimeconfig app be using the default java instead of the java 7 which is the version the tomcat uses the runtime config is running on?
Regards

Hello
We want to run runtimeconfig app exported from OD 7.2.1 on a tomcat with java 1.7.
we get the error: unsupported major.minor version 51.0 while trying to access runtimeconfig app.

Is it possible to run runtimeconfig app exported from OD 7.2.1 on a tomcat with java 1.7? or do we have to use java 1.8 on tomcat?

regards

Hello
We want to upgrade our customer's OD from 6.0 to 7.2.1. Customer is using AES 6.2. And our OD application is AES enabled.

In the Avaya compatiblity matrix for OD 7.2.1, AES 6.2 is displayed under compatible releases but with a note: This version AES connector last validated with OD 7.0.

What does it mean? Will we have problems with OD 7.2.1 and AES 6.2 in production?