Hello,

our application registers CallControlListeners for several devices. Additionally we frequently issue SnapshotRequests for getting further information about ongoing calls.

In general this works fine.

But now we've seen at one installation that both services stopped working suddenly.

SnapshotRequest failed with CstaException. (JavaDoc's exception description 'Thrown if an implementation specific error occurred' is not really helpful at that point).

Beginning with that Exception, all monitored extensions stopped sending CSTA Events.

What might be the reason for such a behaviour?

Is there a way to get informed, if a CallControl monitor has an internal problem that prevents it from sending out CSTAEvents?

Regards,
Claus Suffel

Hi, Claus:

Since this involves a problem at a customer site, please use the "Technical Support" link at the left side of this page for assistance.

Regards,

Nick

Nick/Claus
Field site issues should be escallated through Avaya Global Service (not the technical support link to the left). THat opens a devconnect ticket which is meant to be used for in depth help on applications development issues, equipment related questions, procurement releated questions, licensing, and the like.

For customer impacting issues an AGS ticket is the right path to get immediate help.

It would help to know what version of the DMCC Java SDK you were using (hopefully 4.2.1), the version of Java on the application server and the version of AE Services as well.

Full logs from the AE Services server would also be valuable to collect.

There is a known issue with Snapshot not returning a response in some scenarios. THat was noticed in the .NET version of DMCC but the problem lies in the AE Services server. I do not know how the Java SDK behaves in the face of that issue.

John

Hi Nick/John,

before starting any time-consuming ticket process, I always try to find out, who is responsible for the issue first, Avaya or our application.

To be able to do that kind of analysis, I have some general questions and therefore I've started this forum thread.

One question is the meaningof the phrase 'implementation specific error' in the description of SnapshotRequest's CstaException.

The other question is about the behaviour of a monitor point set via CallControl services in the case of an internal failure. It would be essential for our application to get informed if a monitor stops working due to any reason. In consequence of that, we would be able to display an error message to the user and to retry setting the monitor.

Even if the issue occured at customer site, these questions are of fundamental nature and mainly caused by the vague description in the api docs.
The corresponding answers might be helpful for the whole devoper community.

BTW: We are using DMCC Java SDK 4.2.1

Regards,
Claus

When DMCC switched from proprietary exceptions to using the standardized CSTA errors, there was a significant debate because in doing so it was recognized that considerable diagnostic information would be lost. The CSTA method does not allow application specific information to be included which would facilitate troubleshooting. Without logs from AE Services it is very difficult to identify the source of the problem with the SnapshotRequest, and what impact that may have on call control events.

I am uncertain what events you are monitoring for in your application. I am going to assume that you are only monitoring for call control events because that is all you mention, or that was all that actually stopped occurring and other monitor types continued to work.

I'm going to go way out on a limb and speculate that because SnapshotServices uses the DAPI link, and call control services use a T-Link, both of which are carried over a switch connection (or switch name depending on where in the documentation you read), that the problem originates in a problem with the switch connection (this transports ASAI and DAPI messages between Communication Manager and AE Services).

An application can monitor the link status of the switch connection that a device utilizes by creating a call information monitor and observing Link Up and Link Down events. The monitor will inform the application of DAPI link up/down events. While this is not identical to the T-LINK being operational, in practice it is accurate enough. The case that is not caught is when someone maintenance busies a T-LINK which will impact call control services but not snapshot services.


In regard to knowing if a call control monitor is still operational, if AE Services knowingly ends a call control monitor, the application will be notified with a [call control] MonitorStop event.