Hi there,

I am seeing the following exception being thrown intermittently. This is from getTerminal(). Sometime it works and sometime it doesn't. Can you advise where could be wrong?

com.avaya.jtapi.tsapi.TsapiInvalidArgumentException: not in provider's domain
at com.avaya.jtapi.tsapi.cB.a(SourceFile:1359)
at com.avaya.jtapi.tsapi.cB.a(SourceFile:1335)
at com.avaya.jtapi.tsapi.T.getTerminal(SourceFile:255)
.....

Thanks

Jamie

Hi there

I now consistently getting this message of "not in provider's domain". Is this a sign that I need to restart the AES?

Here is what I discovered: before I call Provider.getTerminal(string) method, I made sure the Provider.getState() is Provider.IN_SERVICE. But as soon as I call getTerminal() I immediately received such an exception of "Not in provider's domain".

Please advise where could be wrong in AES.

Thanks

Jamie

One follow up question to ask, can you tell me what log file to look for at AES side? Also could this be because some resource constraint in AES? (like # of connections and etc.)? I don't know if I am making sense or not. But would like to know where to debug AES from.

Many thanks

Jamie

Is this happening for all extensions? Or just for remote extensions (not on your CM)?

The logs are located in /opt/mvap/logs/ directory on AES

We have 4 ~5 testing station extensions and agent ID. Each agent ID can log to any of these station extension to simulate the agent is roaming around in Call Center cubicles. So the JTAPI code is using the input (the agent ID) to find out the station extension he is currently loggin into.

In the morning, it was working fine that I was able to get all of these 4 ~ 5 agent's station extension back. But later in the day, we start to get some intermittent error for all of them. Later in the day, we were once failing on ALL of them.

Before I left, we were back to intermittent error again for ALL of them. We also restarted the AES (NOT CM). And the result is still the same.

Can you describe what this exception mean in general?

Thanks

Jamie

One more thing to add: we also tested the station extension itself and it seemed to be stable that I was able to register all station extension through DMCC fine without issues. So in other words, whenever we are trying to get the agent's station extension using his ACD login ID, we are facing this error.

(I am sorry for so many replies in this.) I somehow believe this is sort of environmental issues. Can you advise me what are the components needed in AES or in CM to get this working and I will go to admin screen to check each one by one to make sure they are all running.

Jamie,

Do you have the SDB enabled on AES? If so, is the user account associated with your application authorized to control all of the devices in question? It looks like this particular exception should only be thrown if you're trying to control a device that you're not authorized to control.

Joel

Joel,

Thanks for your reply. Do you know where in AES is for this SDB? I am currently login to AES admin WEB UI to look for this SDB.

Thanks

Jamie

Sorry, I should have spelled it out. The SDB is the Security Database. Please see the AES administration guide for details on how to configure it on the release of AES you are using. The overall setting to enable / disable the SDB has moved in recent releases. For older releases it could be found under "TSAPI Settings". For newer releases this is under "Security Database".

I think I found it. Joel, we are currently using the famous "avaya/avayapassword" account in JTAPI application. So this "avaya" account needs to have "unrestricted access".

For example :
in AES admin => OAM Home => Administration => Security Database => CTI Users => List All Users, where this "avaya" needs to have "unrestricted access". Is this what you are referring to?

Thanks

Jamie

Yes. If your user has unrestricted access I don't think you should be seeing this error. If you are, we may have to refer you to the Technical Support link to further debug your issue.

Hi Jamie,

Did u get any solution for this particular issue u have posted below?

Same issue i am getting in my application.?

Please let me know

Thanks,
Manoj

hi
I have the same problem when I run my JTAPI application I've this:

Provider created successfully.

Waiting for the provider to initialize...
Provider is in service.

ACDAddresses for this provider: <none>

Please verify ACD address is correct.

start() caught com.avaya.jtapi.tsapi.TsapiInvalidArgumentException: not in provider's domain
Message: not in provider's domain

Finished executing.Shutting down provider now

To gain access to the AE Services servery you must use a "CTI User". By default (for security reasons) a CTI user is restricted to only being allowed to manipulate extensions (devices) that are provisioned in the AE Services Security Database and associated with that CTI User. Most likely this step has not been done in your environment. Most developers are not concerned with this level of security and use the AE Services web OA&M Security Database settings to change the security setting for the CTI user to 'unrestricted' to bypass this feature. Alternatively you can use the AE Services web OA&M and disable all TSAPI security checking for all CTI users. The third possibility is to configure the Security Database with devices and other appropriate associations for the CTI user you are working with.