Attendant Console-Weird Issue

[Rajesh Revuru]

Hello:

We have this weird issue here. We have two attendant consoles users. Everything works fine, until one of the user loggs off their AC application. When one user loggs off, the other user cannot park and retrieve calls.

Do you know what might be the reason?

[maharris]

Hi! Did you ever find anything on this, we have a new install where one group of users is seeing the same behaviour - one specific user has to be logged in for the other two to see the parked calls in the window..very weird...config appears OK, but I am still looking

[maharris]

Just for the record, this turned out to be an issue with device association - we had the AC users all associated with the ACDeviceAuthenticationUser, but we were not using pilot points, which would be associated to the ac user for control, they were just using the app to control their phones. The two users with the problem were the only two who didn't happen to have a regular user id associated with a phone that matched their ac user id. We added regular user IDs for the users experiencing the problem, and associated those ids with the phones, and things started working fine. It may have also worked to just associate the phones to the ac user, but this made them look like everyone else, for consistency.

Mary Beth

[paolo bevilacqua]

Mary, thanks for the update. Not that I use AC or plan to, but I appreciate those that fix their own problems and take the time to let people know how they did.

[maharris]

Thanks! And I had to come back to update one more time, because it turned out it was not quite working (not sure what they did for earlier test when they said it was), but once we associated the phones to the ac user, it is definitely working now. It also sounds like the problem may have cropped up when they synced to the csr LDAP directory - I don't know if maybe these two user ids started out being in the regular users, associated to the phones, and then got wiped out with the ldap sync, since they are not 'real' users, or what - and all the other users work just fine without having their devices associated with the ac user, so it is just one of those little quirks, I guess..

Mary Beth

[gogasca]

This has been a long time discussion that I've had with some customers (especially the ones that come from the AC old school). Beginning callmanager 5.x onwards it is REQUIRED for AC to use the superprovider role, this is NOT NEGOTIABLE and is a REQUIREMENT from the AC team for the AC app to work properly.

Although superprovider is a role that allows an application to take control of all devices on the fly, *the AC application is built in a way that will require this role in order to successfully control the AC pilots*. Now that is NOT the only change you need/may do to the implementation, besides that the ACDEVICEAUTHENTICATIONUSER could be associated to the phones to be controlled (note only the phones no ac

pilots) if the customer is concerned about a security breach through the AC user. So at the end your AC config should look like this:

Acuser ->> No devices associated *nothing*, superprovider role and call park monitoring.

Acdeviceauthenticationuser ->> all phones to be controlled associated in here, NO roles assigned to this user.

ACpilots are NOT associated anywhere.

The acdeviceauthenticationuser was created to plug the security hole created by the need of the superprovider role and its name can be changed from the AC server/tcd service parameters.

I KNOW that by using the old school associating and user handling the AC would/could work.... that DOES NOT mean that AC is configured properly nor that will work reliably....here has been a number of cases created by this misconfiguration when AC would either fail to fetch control of the pilots of the phone lines or AC pilots would deregister eventually. If you are in any doubt please refer to:

CSCsj07955: 4.1.3 AC config docs suggest devices should be associated to the AC user

HTH