Hello,

In our application we are trying to log an Agent with a SIP extension using feature access code but we are receiving an exception "privilageViolationCalledDevice". Also call control seems not to work in our solution for SIP extensions.

We are able to login to a SIP extension (not Agent) on a softphone and there is no issue with call control on a softphone. We use Avaya Workplace.

We can log Agent in our app with a H.323 extension and call control works correctly.

Also we did not receive any feedback from our Customers that they have issues with SIP extensions in their environments.
What we do not know is - whether using softphone vs physical phone for SIP extension may affect differently our app behavior.

Currently we assume that the issue can be with the configuration of our Avaya lab, but maybe there are limitations e.g. SIP extension call control cannot work with third party application when SIP extensions are used with softphones vs. physical phone.

I would appreciate any help or suggestions about the reason of the issue and the exception. Also indication if it is our Avaya lab issue vs the way how we coded agent login and call control would be very helpful.


Regards,
Mariusz

Two things that you should check:

1. Make sure the CTI link to AE Services, configured on Communication Manager is of type "ADJ-IP". The SAT command "list cti-link" will show this.
2. Make sure that the station configuration on Communication Manager has the following parameter set (on the last SAT page):
Type of 3PCC Enabled: Avaya

Martin

I verified and it looks that both settings are correct (CTI link as "ADJ-IP" and Type of 3PCC Enabled: Avaya).
Is there anything else I can check?

Thank you,
Mariusz

My reading of your description is:

1. You have a SIP station
2. It is possible to use DMCC Call Control (makeCall etc.) to make calls from it.
3. Your problem is when you use makeCall to call the agent login FAC (plus Agent ID & password) in order to login the agent. Correct?
4. Have you tried dialing the numbers from the phone?
5. have you tried using setAgentState to login the agent? You can use the Dashboard to do this.
6. Your question seems to imply that you can login the agent when using a deskphone but not when using softphone. Correct? What softphone are you using? What station type is it configured as?

I am not actually sure if it is possible to use FACs from SIP stations.

Below my answers and annotations to have clear understanding:
Adn.1 I have a SIP extension - is extension the same as station?
Adn.2 It is possible to make calls from the SIP extension when using softphone e.g. Avaya Workplace or One-X. No call control work with our app (we use DMCC) for SIP extension, but everything works correctly for H.323 extensions
Ans.3. Yes, thats correct
Ans.4. We have tried dialing the numbers (only internal extensions) from softphone to softphone - works correctly for SIP and H.323 extensions. With our App based on DMCC does not work for SIP extensions - our issue discussed in this thread, but works for H.323 extensions
Ans.5. We need to try setAgentState to login the agent - code changes needed in our App. Which dashboard do you mean?
Ans.6. This is just an assumption that it works when using a deskphone, because our Customers did not raised any issues. Alternatively they do not use SIP extensions at all and only H.323 that's why there were not issues in our app for them.
We are using mostly Avaya One-X, but also we tried with Avaya Workplace.
The type of the station is 9641SIP.

Does it mean that it may be not possible to use FACs from SIP stations and we should use for example setAgentState to login the agent?

Have you tried your application against our remote lab (which is configured and works for SIP extensions/stations)?
https://www.devconnectprogram.com/site/global/development_tools_configurations/remote_labs/index.gsp#tabs-product-horiz-3

Are you successfully putting a call control monitor (listener) on the extension?
Are you getting error codes back to your call control requests through DMCC? Have you investigated their meaning using the TSAPI for Communication Manager Programmer's guide?

My root guess here is in your lab the stations are not appropriately configured for CTI on SIP stations.
However, you said you can not use the feature access code to log the SIP agent in - correct? That would eliminate a CTI issue - at least for that problem.

Is the COR/COS for the station extension you are working with allowed to access agent functionality? There is a flag somewhere that controls that if I recall properly.

I have not tried remote lab yet. Thanks to your link I requested access to the lab, but not received it yet. In the meantime I was reading remote lab manual and I found the following information:
"SIP softphones are not controllable through CTI requests".
Also there are no softphones that we use (One-X and Workplace) on the SIP support page.

Does it mean that we cannot use our application against softphone with SIP extension logged? Only a SIP desk phone call control can work with our app?

According our developer call control monitor (listener) on the extension works correctly.
We are getting different errors back to our call control requests through DMCC, but as a starting point we focused on the login and

privilageViolationCalledDevice

exception. Should we look at different error first?
We are trying to engage Avaya team in help for configuration of our lab, to have it correctly configured for CTI on SIP extensions, but it takes time so I am looking for the root cause also here in the meantime.

My knowledge is poor about the lab config, so I only know that for the used SIP extension COR and COS are set to 1, but I do not know what does it mean now. I will search the answer, but any suggestions for that would be valueable.

Thank you,
Mariusz

The statement regarding SIP Softphones not supporting CTI call control is out of date. You should be able to do call control for Avaya Workplace and one-X. The underlying issue is overall clarity about CTI support by a particular softphone is not in a centralized place within Avaya and it has changed over the years (releases) of the products.

a cos/cor value of 1 merely says you are using configuration number 1 it doesn't tell us how that configuration is setup (which is totally customizable). The error message leads one to think there is some restriction in place there are a number of places to look.
The security database on AE Services may be enabled
The class of restriction of the calling and called parties may block a call from being made between them

An agent login request doesn't really have a called party involved, but sometimes one chooses a similar error message from the list as opposed to creating a new one.

However if CTI call control services are not working in general, one needs to understand why that is. Martin listed the normal places to check, has that been done?