Hello ,

I have an application written against an earlier version of the TSAPI. Release 4.2.
The purpose of this application is to receive notifications as calls get to delivered to the initial agents and subsequent agents; and as those agents answer that call.
Once this application gets that notifications, it passes information along to another application. The management of this application has been passed onto myself.

The application is performing this task with some issues.

As far as the intial open stream, here is the information on that:

OpenTSAPIStream: PrivateData Length 9, Requesting versions 5-8.

EventACSOpenStreamConf.
EventACSOpenStreamConf: API ST2, Lib AES8.1.0 Build 9, TSrv 8.1.3 Build 4, Drvr 8.1.3 Build 4.


It performs the acsGetEventBlock(_AcsHandle, _EventBufPtr, &EvSize, (PrivateData_t *)&privateData, &numEvents);
without issue and then makes some calls to the cstaMonitorDevice to monitor the agents extensions/device ids.

The application does get notified when calls are delivered to these device ids. I'm having not problems using the invokeid in the call.
eventHeader.eventType is CSTA_DELIVERED and my logic to gets executed. I also receive and event for CSTA_ESTABLISHED and am able to work with that.

Right now , after the application receives the CSTA_DELIVERED event, its makiing a call to cstaMonitorCall and then the API responds with a Universal Event Failure error code 44. According to documentation, that error code means the number of monitors on that call is at the system limit. That makes sense to me.

My question is see how I'm already monitoring a device with the cstaMonitorDevice (real world an agent who has logged into Avaya) , do I need the subsequent call of cstaMonitorCall for every call that comes into that agent. I would think monitoring an agent might be enough but I am asking to confirm that.

I really just need to get notified of when agent gets a call delievered to them and they answer it. As long as I can get the UCID for call delivery and call establishment (which is taking place as well) without having to do the cstaMonitorCall, I think I can clean up some code and totally avoid this error condition.

Hopefully I have stated myself clearly and provided sufficient detail so that my question is clear.

Firstly, I am not sure why you are getting an error for cstaMonitorCall. The device monitors will not lead to cstaMonitorCall failing. The main reason the cstaMonitorCall could fail is that another application is running (using this AES or another one) which has performed cstaMonitorCall (or other function that causes AES to take control of the call).

That leaves the question about whether the cstaMonitorCall is needed or not. In many cases there is no need for a cstaMonitorCall. This will depend on your situation.

The only time I think cstaMonitorCall is really needed is if:
1. The call could be transferred to another non-monitored device AND
2. The application still needs to track the call after the transfer.

As you describe it, I do not think you need cstaMonitorCall.

Martin