Hi,

We are developing a cti application using tsapi sdk.
hold-unhold feature is working perfectly fine.
But when we add ACR for call recording unhold fails.
When the call is put on hold, the existing recording extension gets disconnected.
Now when we try to unhold the call we get resource busy event.
Is there a way through which this can be resolved

Thanks in advance.

I would need to know more about how ACR was activating recording and what CTI actions it was taking. My first suspicion is that it took some action that placed a "call monitor' e.g. Took Control of the call which prevents other applications from making CTI requests on the call.

1) can the physical device unhold the call?

2) are other CTI actions from your or another application blocked (say disconnect the station from the call, or single step conference a party into the call)? You can use the DMCC Dashboard to test these scenarios without having to extend your application's logic.

3) The operation you would be looking for is a third party take control. i believe that would be a message that includes the string 3PTC or 3P_TC. If ACR is using CVLAN or DLG you won't find the evidence in a TSAPI g3trace, you would need to get a MST trace from Communication Manager with ASAI tracing enabled and get it interperted to prove this is the source of the issue. If it is using TSAPI this interaction should not be a problem. You could start looking to see if ACR is using those protocols by looking ot see how AE Services is configured (are there switch connection links configured for those services?).

Unfortunately, if some other application is taking control of the call using CVLAN or DLG, by design that blocks your application out.

I cant think of another interaction that would cause the problem you describe. If ACR is using a TSAPI based service to do recording, nothing comes to mind other than looking close ly at the TSAPI trace logs and understanding how ACR behaves in this scenario and trying to understand what resource is unavailable for the unhold.

Hi John,

Below are the details:

we have ACR r11 and this is a DMCC based active recording. The call recording is happening using “Service Observing” and “Single Step Conferencing”

We are using One-X Agent and we can unhold the same call from One-X Agent

We are having ACR only in this architecture and OneSys is the only CTI Application.

We have 2 AES Instance in this architecture.
1st AES (Release 5.x) is integrated with ACR
2nd AES (Release 6.x) is integrated with OneSys.
Both the AES has been connected with Same Communication Manager (CM6.3)
Pls confirm in which AES server we need to enable the Advance TSAPI Trace?
Also suggest us whether can we raise the case to Avaya BBE to get further support to analysis this TSAPI Traces and CTI Messages.

AFAIK, ACR uses TSAPI. So, if ACR and your application are using the same AE Services, there should not be a problem with Take Control. However, if ACR is using a different AE Services to your application, you will see the problem that John has described.

Martin

Hi Martin,

ACR and TSAPI are on different AES.
But one of our customer has both on single AES. Still we are facing same issue.

If your application has been compliance tested by Devconnect then your customer can open a ticket with Avaya Client Services.

Martin

Pls confirm in which AES server we need to enable the Advance TSAPI Trace? Tracing would need done from the perspective of ACR since it is doing something that is locking your application out. So the activity on the AES running 5.x is the information you need.

Also suggest us whether can we raise the case to Avaya BBE to get further support to analysis this TSAPI Traces and CTI Messages.
You can create the SR I dont think it will get you a solution though. Given 5.x is out of support, and probably 6.x is as well I don't know if they will engage. Software patches to most of those releases are no longer available (only 6.3.3 build 144 is available IIRP). If I were to go that route, I would first prove that your app has nothing to do with the problem by using the DMCC Dashboard, TSAPI exerciser or JTAPI exerciser to reproduce the issue. This way you can state that the issue has nothing to do with your application with total confidence, and use that to convince BBE that the interaction lies in the Avaya kit.

IIRP SSC does take control. Service Observing would not do a take control to the best of my knowledge.

As Martin says, assuming ACR is using TSAPI, and your application and ACR are using the same AES, then the take control would not impact your application. Again some testing with one of the protocol exercisers could prove that.

5.x and 6.x are relatively old releases, and those are non-specific lease references. It could be that there is some product issue that Martin and I have forgotten about.