Solved: CUPC Unable to Control Deskphone

Robert Juric · ‎05-03-2010

Our CUPC clients have lost the ability to control the deskphone. The option is there to select the phone in CUPC, and deskphone control has been assigned to all users, however when you select deskphone it pauses and then moves to disabled, the softphones are working fine. This is probablly caused by some setting I've changed, I'm just not sure exactly what the problem could be?

Any help would be greatly appreciated,

Robert

htluo · ‎05-03-2010

1) On CUCM > System > LDAP > LDAP Authentication > change the port to global catalog port (default is 3268).

2) Restart CTIManager on all CUCM nodes.

Michael

http://htluo.blogspot.com

View solution in original post

CHRIS CHARLEBOIS · ‎05-03-2010

First thing to verify is that the phone device are still associated with the user. I can't think of what might have caused all the devices to become unassociated from the users, especially if the UPC devices (the softphone instances) are still associated. But it is something to check.

Aaron Harrison · ‎05-03-2010

Hi

A few other pointers:

- 'Deskphone control' as an assigned feature in the CUPS web interface has nothing to do with CUPC; it just refers to deskphone control for MOC clients.

- A common cause for this failing is auth timeouts if using AD integration on CCM - are you using that?

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Robert Juric · ‎05-03-2010

Yes we are using AD integration. I did read something about changing the port listed for AD integration in the documentation. Is that something you would recommend?

Robert

htluo · ‎05-03-2010

1) On CUCM > System > LDAP > LDAP Authentication > change the port to global catalog port (default is 3268).

2) Restart CTIManager on all CUCM nodes.

Michael

http://htluo.blogspot.com

Robert Juric · ‎05-04-2010

The LDAP server port was already set to 3268. Should I change this? This problem is currently affecting just about everyone.

htluo · ‎05-04-2010

Was CTIManager ever restared after the port was set to 3268?

If that has been done, we need CUPC problem report and CTIManager logs (at detailed level).

Thanks!

Michael

Robert Juric · ‎05-04-2010

The port was never changed, it was set to that from the time of implementation. I can still try to restart the services this evening.

Robert Juric · ‎05-05-2010

My mistake, I was looking at the LDAP port under a different setting where it had been set already. I corrected this under the LDAP > Auth. section and restarted the CTIManager services. Fixed that issue!

Thanks for the help,

Robert