cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1538
Views
5
Helpful
6
Replies

Cucimoc - cannot switch to desk phone mode

Roland Theisen
Level 1
Level 1

Hello,

I am facing a strange problem with Cisco Cucimoc. The softclient of CUCIMOC works perfectly but as soon as I want to switch to my deskphone the application hangs and gives the error message "Phone Error. Service internal error. [101]"

Additionnaly, the Desk-Phone portion in the "Server Status" panel remains in the status of "connecting". All other portions (LDAP and Softphone) are green.

The CTIManager Service is up and running on my callmanager cluster.

My end user account is well assigned to the "Standard CTI Enable" group and the "Allow CTI control" checkbox is click in the configuration page of my desk phone. To my end user account I have assigned my desk phone and the Cucimoc under the controlled devices.

On the DN page, I have assigned my end user account.

The version of my callmanager is 7.1.3.32900-4 and the Cucimoc version is 7.1.4 and my laptop is Windows 7 32bit enterprise edition. For test purposes, the anti-virus and firewall had been removed from the laptop. Additionally, I've put the laptop in the same network as the Callmanager. But all these actions didn't solve the problem.

Can anybody help me with this issue? If additional information are required, please feel free to contact me.

Thanks a lot in advanced.

Marc Hoffmann

1 Accepted Solution

Accepted Solutions

Hi Marc,

Thanks for replying. I am not an AD expert but my guess is that we are not pointing to Global Catalog hence you could not even login to ccmuser page.

3268 is used by global catalog and is the recommended port to use when you are doing ldap searches or sending authentication requests. In any case you can ask your AD admin for more information on this. It might be worth trying.

Now, what we would normally ask is CTIManager SDL Traces, tomcat security logs and a sniffer capture ideally from the callmanager (where the ctimanager resides) and the AD.

What I am interested to see is where the whole authetication process fails (if this is the case that is)

Not sure how feasible this is in the forum as we don't want to expose any sensitive data out to the public domain. An easy way for you would be to take some sniffer captures from the callmanager and filter based on the LDAP traffic.

To enable the sniffer in callmanager you need to issue the following from the cli

utils network capture eth0 size ALL count 100000 file cucm

and then you can collect the capture from RTMT (network capture logs)

Regards,

Christos

View solution in original post

6 Replies 6

Hi Marc,

Do you have LDAP integration / authentication ?

Usually in these cases we make it work by changing the LDAP port for the authentication from 389 to 3268 (if applicable)

Can you restart CTIManager after that ?

Regards,

Christos

Hello Christos,

Thanks a lot for your reply.

Yes, we have LDAP integration and authentication in the callmanager.

As LDAP system we use Microsoft Active Directory (Windows 2008 R2) and as LDAP attribute for the "User ID" we are using "employeeNumber".

The LDAP authentication is also enable, I am pointing to our main Domain Controler and I am using the port 389.

To login on the CCMUser page or in the Cucimoc, I have to use my employeeNumber and my normal Windows password. Login in with my normal Windows username and the corresponding password does not work in either cases.

I've tested it yesterday to change the port from 389 to 3268, restarted the CTIManager Service but it did not solve the problem. I was no longer able to login neither on the CCMUser site nor on the Cucimoc. I used my employeeNumber (as User ID) and my normal Windows password to login but then I get the message "incorrect Sign-in credentials".

Just to make an additional test, to tried to login with my normal username and the corresponding Windows password but also with these credentials it failed to login (in Cucimoc and CCMuser page).

Thanks a lot in advance for your help and best regards,

Marc Hoffmann

Hi Marc,

Thanks for replying. I am not an AD expert but my guess is that we are not pointing to Global Catalog hence you could not even login to ccmuser page.

3268 is used by global catalog and is the recommended port to use when you are doing ldap searches or sending authentication requests. In any case you can ask your AD admin for more information on this. It might be worth trying.

Now, what we would normally ask is CTIManager SDL Traces, tomcat security logs and a sniffer capture ideally from the callmanager (where the ctimanager resides) and the AD.

What I am interested to see is where the whole authetication process fails (if this is the case that is)

Not sure how feasible this is in the forum as we don't want to expose any sensitive data out to the public domain. An easy way for you would be to take some sniffer captures from the callmanager and filter based on the LDAP traffic.

To enable the sniffer in callmanager you need to issue the following from the cli

utils network capture eth0 size ALL count 100000 file cucm

and then you can collect the capture from RTMT (network capture logs)

Regards,

Christos

Hi Christos,

Thanks a lot for your advises and the cli command.

I will run some traces and see what's the output.

I will keep the discussion up to date at soon as I found something.

Best regards,

Marc Hoffmann

Hello Christos,

I want just inform you that my problem with the CUCIMOC is solved now. The problem was with the LDAP attribute "employeeNumber" which we used as "User ID" in the callmanager. The LDAP attribute does not exist in the Global Catalogue, so the CTI process failed to authenticate against the Active Directory.

After a discussion with your AD administrator, we've added the "employeeNumber" attribute to the Global Catalogue, waited the replication of the domain controllers to be completed and after that my CUCIMOC client started to work fine:-)

Thanks a lot for your help.

Best regards,

Marc Hoffmann

Perfect!

Thanks for posting the solution here Marc.

Christos