Hi,

I know that if the TSAPI client API loses connection to AES the TSERVER_STREAM_FAILED event is sent and the link is down, but if the cti link between the CM and AES fails the TSAPI client does not seem to receive anything to indicate this other than individual monitorEnded events etc.

Is there anyway of detecting this failure or confiuring the client to report stream failure if the cti link has gone?
I am trying to use alternate tlinks but this failure condition doesn't allow the client to try an alternate.

I am unclear on why you feel the events you are getting are inadequate.

If you get a monitor ended, and can not re-establish the monitor using the same stream/T-Link, then open another stream to the alternate T-Link and attempt to establish the monitor on that stream. Some applications open both streams as they initialize, and setup half the monitors on one stream and half on the other. That way they get a 'better' indication of T-Link failure and they impact fewer clients if and when it does occur.

Its because our our has always been based on using a single Tlink connection. I can see the advantage to working with two, but that is something to think about for the future.

The problem with a monitorEnded event is that it doesn't force the tsclient to use an alternate tlink so it is down to the application to make a decision based on the number of failures on the current link and to try connecting to another one.

So you are expecting AE Services to decide to use an alternate path than the one your are specifying. There are issues with such automated decision making trying to out smart what the applications using AE Services are doing that Avaya isn't in the best position to be making those choices; thus the decision about when to decide an alternate path is the right thing to do, and which T-Link to use are left to the application.

I assume you have read and understand the section regarding CTI Link Availability in Chapter 2 in the TSAPI for Communication Manager Programmer's Guide (I am using Release 4.2, May 2008, Issue 4 the most recent version), and you have also read System and Link
Status Notification (Chapter 13: System Status Service Group)

I was simply enquiring whether the AE Server a TSAPI application is connected to, could decide to end the cti stream to that application if the cti link to communication manager has gone. Certainly never suggested AE Services to do anything of the sort.

The configuration of alternate Tlinks is specified in the TSLIB.INI file and if connected to the AE Server is lost when attempting connection to that link the client will try an alternate tlink.

If the stream is established between the app and AE Services, and subsequently the T-LINK between AE Services and Communication Manager fails, the application is notified of the failure, BUT the stream is not disconnected.

With alternate T-Links, the TSAPI client ONLY uses an alternate T-Link from the list if a stream to the primary (and all earlier alternate T-Links on the list) can not be established.

I was not aware that the application is notified of the tlink failing between CM & AES? Unless you mean monitorEnded? If so are there not device specific reasons why monitorEnded is received or can we always take this as a link failure?

That is why I mentioned that you read System and Link
Status Notification (Chapter 13: System Status Service Group).

You ALSO receive monitor ended notifications (if you have active monitors). There are other notifications your application MAY receive (which is why I suggested you read CTI Link Availability in Chapter 2.

There ARE device specific reasons for a monitor ending that do not imply the T-Link has failed, however IF the T-Link fails you WILL get monitor ended events.

Apologies John, not sure how I missed that. I will take a look at that chapter.

Regards

It is worth warning you that I entered a couple of Modification Requests against release 4.x of AE Services for scenarios where the Link Down events were not being posted to applications. If you are not on the current 4.2.x or 5.2.x GA load you should get there before doing much testing with the Link Down/Link Up events. If memory serves there is another thread that has some details in it about this problem.

P.S. It is a long boring document... I can't stay awake through it either.

Well reading that chapter has been very helpful, I've been looking after our TSAPI driver code for about 10 years or so now and for some reason not looked into these events, I guess I assumed the person that had it before had done all that was possible/necessary in that area, I will learn from that.

I've been testing these events on our 4.2 AES and they seem to provide useful feedback for when there is one CTI link. Thanks again for your help.