CUCM Version 11.X
IM/P Version 11.X
Jabber version 11.6
Jabber for windows not able to move to Deskphone mode ,Gives me error "Unable to connect CJ:109:3" ,
-> UC service
CTI service 1 :FQDN(primary) and port 2748
CTI service 2 :FQDN(secondary) and port 2748
CTI service 3 :FQDN(Ter) and port 2748
Primary `: CTI service 2
Secondary: CTI service 3
Tertiery : CTI service 1
-> Cisco IP phone 7942
Owner ID "User ID"
Checked : "Allow Control of Device from CTI".
-> The end user id
Primary Extension :
Cisco IP phone extension number
group permissions included;
standard CCM end user.
Standard CTI enabled.
I suspect your issue will be one of two things.
Your LDAP port is 389 if you are using LDAP authentication (Change it to 3268)
You have not got the right user rights
you need to add "Standard CTI Allow Control of Phones supporting Connected Xfer and conf"
try these and I think you will have success
I have changed the LDAP port number to 3268In LDAP authentication and LDAP Directory
Added the group permission "Standard CTI Allow Control of Phones supporting Connected Xfer and conf"
Still the same issue
if it is using extension mobility you need to give the end user CTI Control of the user device profile
if it is not extension mobility you need to give the end user control of the SEP device.
After this it should work. I Can't think of any other reason it wouldn't, if allow control from CTI is ticked on device, UDP And end user, phone/UDP is associated and end user has correct access rights and LDAP is port 3268.
Try restarting both the jabber client, PC, and logging out and in again to the phone if you have extension mobility. Also ensure no firewalls blocking the traffic between your data VLAN (Jabber) and voice VLAN (IP Phone)
also ensure CCMCIP profile is configured in IMP Server, and that everything can resolve the FQDN of the CTI Profile.
Can you post a screenshot of "show connection status" Of jabber?
Attached "show Connection status" for jabber 9.7 version
I tried telnet from the PC to CUCM IP ,Port number 2748 ,Telnet is good
Reinstalled the jabber and rebooted the PC ,All the jabber have the same issue
end user :
Cisco 7942(SEP+MAC) already added
I believe I have mentioned everything that is required for deskphone control with a good configuration in other areas.
Looking through the logs quickly, connectivity seems unstable. Can you confirm your network architecture? Any firewalls between phone / PC / CUCM? Have you turned off windows firewall or any windows security software for testing purposes? Is everything in the same domain and can resolve everything else by name?
2016-09-28 12:07:18,783 ERROR [0x00001a34] [ice\TelephonyAdapterServerHealth.cpp(82)] [jcf.tel.adapter] [CSFUnified::TelephonyAdapter::getConnectionIpProtocol] - No connected ConnectionInfo of type: [eCTI]. Could not determine connection IP Protocol
2016-09-28 12:07:18,783 DEBUG [0x00001a34] [\impl\TelephonyServerHealthImpl.cpp(279)] [jcf.tel.health] [CSFUnified::TelephonyServerHealthImpl::updateHealth] - updating health with serverType [CucmDeskphone] serverHealthStatus [Unhealthy] serverConnectionStatus [Disconnected] serverAddress [ (CTI)] serviceEventCode [UnknownConnectionError] transportProtocol [CTI] ipProtocol [Unknown]
2016-09-28 12:07:18,783 DEBUG [0x00001a34] [\impl\TelephonyServerHealthImpl.cpp(279)] [jcf.tel.health] [CSFUnified::TelephonyServerHealthImpl::updateHealth] - updating health with serverType [CucmDeskphone] serverHealthStatus [Healthy] serverConnectionStatus [Connected] serverAddress [ (CTI)] serviceEventCode [Unknown] transportProtocol [CTI] ipProtocol [Unknown]
2016-09-28 12:07:18,783 DEBUG [0x00001a34] [\impl\TelephonyServerHealthImpl.cpp(279)] [jcf.tel.health] [CSFUnified::TelephonyServerHealthImpl::updateHealth] - updating health with serverType [CucmDeskphone] serverHealthStatus [None] serverConnectionStatus [Disconnected] serverAddress [ (CTI)] serviceEventCode [Unknown] transportProtocol [CTI] ipProtocol [Unknown]
Ive also noticed you seem to have medianet 11 installed:
2016-09-28 12:07:14,611 INFO [0x00001738] [control\CallControlManagerImpl.cpp(3825)] [csf.ecc.api] [csf::ecc::CallControlManagerImpl::setMedianetClientVersion] - setMedianetClientVersion="18.104.22.168957"
But jabber 9?
Can you confirm the versions of everything tha tyou have?
Would it be possible to try another machine or VM? could you also confirm the hostnames of your call managers?
It seems some things are connecting to atcm-dc-2.atheeb.com and some to athcucpub01.atheeb.com. I know its only a lab system but ATCM-dc-2 seems to be a domain controller from the name? I may be wrong.
I'm experiencing the same issue, has anyone been able to solve this?
local users in CUCM have no problem controlling phones, but LDAP users are having issues. We have restarted the IM & P cluster along with the CTI manager service in CUCM.
The AD user used for LDAP authentication did have a password change but LDAP auth via Jabber / UCCX are working fine along with directory synch.
if you can share the PRT i can look at that.
Also is it a LDAP user or local user ? For LDAP please follow the port settings mentioned on the thread.
Try with local user first if you are able to do that. Also what version of CUCM, IM&P you are running ?
I have the same problem after I enabled the SSL LDAP integration with CUCM, before it was working fine. Does someone know what could cause this ?
you must verify this whether ip address or hostname is located in the ssl cert ...
Check this check box to use SSL encryption for security purposes.
If LDAP over SSL is required, the corporate directory SSL certificate must be loaded into Cisco Unified Communications Manager. The Cisco Unified Communications Operating System Administration Guide describes the certificate upload procedure.
If you check the Use SSL check box, enter the IP address or the hostname that exists in the corporate directory SSL certificate in the Host Name or IP Address for Server field in the LDAP Authentication Configuration window. If the certificate contains an IP address, enter the IP address. If the certificate contains the hostname, enter the hostname. If you do not enter the IP address or hostname exactly as it exists in the certificate, problems may occur for some applications; for example, applications that use CTIManager.