We have one CTI application which connects to AES and creates a conference call (I think it is using CVLAN but not completely sure), and separately we are using TSAPI, and calling ClearConnection to disconnect one of the calls in the conference call.

We were successful to do it when the conference call was created by TSAPI, but getting OUTSTANDING_REQUEST_LIMIT_EXCEEDED error when the conference call was created by the CTI application.

Just wondering if this is an existing behavior and if there is a way to work around this.

Thanks,

Certain commands require AE Services to "Take Control" of a call on Communication Manager. One example is MakeCall. Only one application can Take Control of a call.

So, if when the CVLAN application is used to make a call, it is not possible for another application (CVLAN, DLG or TSAPI/JTAPI/DMCC) to perform some functions on that call. Also, applications on another AE Services will be limited in the same way.

THere is one exception - TSAPI shares control among applications (TSAPI, JTAPI and DMCC) on the same AE Services. So, if a TSAPI application makes a call, other TSAPI/JTAPI/DMCC applications on the same AE Services can also control the call but CVLAN applications or other applications on other AE Services cannot.

This is a hard limit and there is no way to overcome it, apart from migrating your CVLAN application to TSAPI, JTAPI or DMCC.

Martin

It would be helpful to know if the problematic conferencing app was using CVLAN or not. CVLAN requires a link to be configured on AES and on Communication Manager that would be separate from the TSAPI link. In the AES web interface in AE Services there is a section for CVLAN provisioning. You could examine it and maybe get some insight.

One of the 'problems' with CVLAN and DLG is that it has the means to put a lock on a call and prevent other applications from manipulating the call. Since the development team tried to map the various failures into a relatively small group of CSTA error codes, often the error message is not all that meaningful. One interpretation of Outstanding Request Limit Exceeded, is something else is preventing your request from being processed. With TSAPI alone, it would mean that if you repeated the request there is a good chance it would work... it is thrown when Communication Manager is already processing a message (has not completed) and another request shows up that would operate on the same objects/resources, the second request receives that message.

TSAPI doesn't put a lock on a call, so I have little experience with how the system behaves when it encounters one. Maybe what you are describing is that behavior, I am not sure.

So does repeating the request get different results? It may be easiest to use the TSAPI Exerciser to perform this test.
If the clear connection is repeatedly rejected, I am going to assume CVLAN put a lock on the call and you can't do anything with that call other than through the CVLAN app that has the lock.

To understand better if there is a lock on the call you would need to look at an ASAI message sequencer tracer trace from Communication Manager and look for a particular message from ASAI (indirectly from the CVLAN app) that "takes control of the call" (that is what I mean by a lock). The messages in ASAI are pretty cryptic so it is going to be something like CVTC message using a call reference value, but there would probably be other messaging related to extensions that you could recognize at the point the app builds the conference that you could pick off the call reference from and then look through the messaging to see if you saw something that looked like the take control. If you have a copy of the ASAI spec, you may find the message described therein as well.

Thanks a lot Martin and John for the insights. I will look into points you provided.

But there is one thing I forgot to mention. We are actually able to clear the connection of the station (the agent), which has devIDType STATIC_ID and initiator of the conference call, even when the conference call was created by the CTI application we have. And we are failing to clear the connection for other devices that have devIDType DYNAMIC_ID. So it seems like the connection of the station can be cleared whether there is a lock on a call or not.

I tried clearing the connection on the device with devIDType DYNAMIC_ID repeately as John suggested, and was rejected constantly.

Also, actually our final goal is to put SLH on one of the calls, not clearing the connection. We were testing the flow with Clear Connection while we wait for TSAPI advanced license. I am now wondering if SLH have the same behavior, if it will work on the station only just like Clear Connection.

Thanks a lot,

Dynamic Device IDs represent trunks (almost all of the time). I suggest switching your test to two stations instead of a station and a trunk call.

I would think you could clear a trunk from a call, but there maybe something in the configuration of the trunk preventing that (e.g. disconnect supervision). You could also try switching the direction of the call over the trunk to see if it makes a difference (outbound instead of inbound or visa versa) since that can have an impact on disconnect supervision.

You could also just use hold in lieu of clear connection for your testing work.

We got the TSAPI advanced license, and now we are testing SLH, and we are getting OUTSTANDING_REQUEST_LIMIT_EXCEEDED.

The call is initiated from CVLAN, and we are trying to do SLH on the station.

ClearConnection worked when used on the station even when the call is initiated by CVLAN, so we were hoping SLH would work, but apparently not.

We are guessing it is because CVLAN is taking control of the call, but just want to confirm if that is correct, because we were able to use ClearConnection.

DevConnect does not support CVLAN thus our knowledge is limited.
From Communication Manager configure and enable message sequence tracing (MST) on ASAI messages for the CTI link that goes to the AES in question (or all).
Initiate the call from CVLAN make note of the timestamp from Communication Manager's perspective using a linux date or SAT display date (or is it display time) command?).
Verify you can not do the selective listen hold from your application.
disable MST.

Use the Communication Manager web interface to look at an interperted MST trace (note trace analyzer on the MST form must be enabled for this step to work).
Look at the interpreted trace and see if you can see CVLAN launch the call. In that portion of the trace look for a 3PTC (third party take control) message containing the call reference ID for the call. If so then CVLAN took control of the call and locked other applications out.

This is one of the drawbacks of CVLAN and DLG applications.

Why don't you manually place a call and use it to verify your SLH functionality?