Hello,

our application initiates a single step conference (silent mode) from an active call to a softphone controlled by the app.

This usually works fine, but in some rare cases, establishing SSC leads to a PrivilegeViolationSpecifiedDeviceException.

What is the meaning of this kind of exception?
What could be the reason for getting those exceptions?

Regards,
Claus Suffel

BTW:
After the redesign , the 'Subject' and 'Release' fields of the forums enter mask appear unreadable small in my Firefox 3.0.11.

Hi Claus,

These errors indicate that there was a problem with authorization in the AES Security Database (SDB). If the SDB is enabled and your application user does not have unrestricted access, the user must be authorized to control the device that is being added. This is because the deviceToJoin is being forced offhook. Please see our administration and maintenance guide for further details on the SDB.

Joel

Hi,

I am also seeing this issue on one particular setup, I have never seen it before, but a good percentage of calls are failing to record as my SSC's keep failing with this error.

I'm not sure I understand the explanation, how do I go about resolving this? Looking under the 'Security Database' menu on the AES web config and the 'Control' sub-menu, 'Enable SDB for DMCC Service' is unchecked, should this be checked? What does turning it on do?

Thanks.
Adam Cobb.

Unless you want to utilize the Security Database, I suggest you leave it unchecked. Life is much simpler without it. Turning it on imples that all devices your app works with must be provisioned into the SDB, and your app must be given permission to work with them. Otherwise your requests are blocked. This is described in the AE Services Administration and Programming documentation. Customers use these services to make sure app X does not manipulate/observe station A's calls, while allowing app X to manipulate/observe station B's calls.

That exception may be related to trying to single step extension X into a call involving Y and Z. If the COR (class of restriction) of X does not allow them to participate in a call using the COR of Y and Z you may be blocked. The TSAPI documentation uses similar sounding event to indicate a COR violation occured. It is not crystal clear what that meant.... make sure the COR used for X (your recorder) is set to yes for all other CORs in the SAT 'change cor A' form.