First try using subdialog instead of local call. I talked to another developer and he said with local call you could have some nesting issues that deep.

If you are still having issues, post an app log here.

Should only be limited by the VM. How deep is your nesting and what behavior?

You should bring this to EP support.

Is it possible the server is not able to keep up with the traffic? Do you need to unload to a 2nd server?

It should be the threads from Websphere. How busy is your system at peak hours?

I need to see both an app log and an AESC log for the same call. It would be best to delete the old app/AESC logs and just test it for one call so the logs aren't so large.

When you start the AESC, JTAPI will set up an observer thread on each incoming channel/extension that you map. The threads will wait for an event to occur, which it appears they are doing from your logs.

This should be the normal activity. If you are having thread issues, you might need to increase your overall thread count in the JVM.

No, you can only have one ICC per JVM. You can have multiple Tomcat servers with their own ICC and you can direct traffic between them.

Do you have any logs showing the timeout issues? ICC is pretty efficient. It just acts as the go between from the app to IC, so there really isn't a lot of overhead for it to bottleneck.

How much traffic are you handling with this appserver? It could be Tomcat itself that is running out of threads. You might need to look at your Tomcat setup and add more heap space and thread count if that is the case.

It looks like the “open session” returns some sort of cookie or other piece of data that the second request is using to verify there is a session. The Chrome client seems to magically persist this and add to the second request.

look at the raw http request returned on request 1 (including http headers and etc) and then also look what is sent in the second request (raw request, including http headers) that should uncover what should be sent in the second request.

Do you have the app log showing it invoking the first call successfully?

Is there anything about the second call that would cause a security issue beyond just invoking it?

system.out won't go to your trace logs. You should use

mySession.getTraceOutput().writeln(ITraceInfo.TRACE_LEVEL_DEBUG,"some debug here");

Have a look at this thread: http://stackoverflow.com/questions/7478406/wsdl-cannot-find-dispatch-method-for
Is it possible there should be a slash after 1.0?
Calling method [{http://com.tcs.bancs/FetchDepositBalanceIVR/1.0}fetchDepositBalanceIVROperation]

It could be a few things. I would think most likely a certificate issue possibly?

Try this link for some ideas:
http://stackoverflow.com/questions/370420/http-403-error-while-accessing-web-service

It looks like it is storing it as a collection of size 10. if you iterate over the collection, it should retrieve each value.

PnCMenu:value[1] as [8]
...
PnCMenu:value[10] as [8]

Please review the chapter - "Application Deployment" in your AAOD Dev Guide
Specifically the section:
"Orchestration Designer Admin (ddadmin) Web application configuration"

You might also want to look at the Web Services section as it does have some discussion on certificates.