CUPC 8.6 Desk phone control

[mattcalderon]

Currently running CUCM 8.6 along with CUPS 8.6.  Currently we are able to get the softphone to register and make calls, but we can not get deskphone control.  When we look at server health on the CUPC client, we just keep seeing "Connecting" and the correct servers are identified.  We do have the user set in CUPS with the CTI_Gateway application profile, we have the phone associated with the user, in CUCM,  we have the user in the correct end user call manager groups, and we have the line associated with that user. Not sure what else we are missing here.

Matt

[madhusudhana.vatala]

Please check with Standard CTI Allow Control of Phones supporting Connected Xfer and conf user group for 89xx/99xx series phones and Standard CTI Allow Control of Phones supporting Rollover Mode for 69xx series phones.

[mattcalderon]

Good point. Should have mentioned I am running 7945 Phones with Sip firmware

Sent from Cisco Technical Support iPhone App

[Aaron Harrison]

Hi

Do you also have 'Primary Extension' set to the line you want to control?

Check you have 'CTI enabled' check box set on the line/phone, and also on the end user if you are using EM.

Regards

Aaron

[Jason Newman]

Matt,

In all my experience with troubleshooting CUPC Desk Phone control issues the "connecting" message in the help show server health typically points to a CTI Manager login failure.  There is an easy way to confirm this:

Enable detailed logging on the client, restart it and try to obtain desk phone control.  Immediately create a problem report.  In this report you can go to CUCSF-XXXXXXX -> Client Services Framework -> Local Settings -> Logs -> CiscoJtapixx.log  (select the most recent one based on timstamps).

You will see the following sequence of messages:

com.cisco.cti.protocol.ProviderOpenRequest

com.cisco.cti.protocol.ProviderOpenResponse

com.cisco.cti.protocol.ProviderOpenCompletedEvent

In the Provider Open Completed event you will more than likely see an error message in the failure description.  This typically is a simple failure or a directory login timeout.

If this is the case the most common cause is due to the LDAP Autheentication settings on Call Manager.  Typically people are using 389 which can not respond in time and cause these timeouts.  I recommend trying to use port 3268 (the global catalog port).  If you need to change this LDAP setting you will need to restart the CTI Manager service on all nodes for it to take effect.

If you have issues diagnosing the problem, don't hesitate to post the problem report.

Regards,

Jason