I have installed the latest CUPS and CUPC and integrated it towards CUCM 6.1.3 according to the manuals. All the end users, devices and lines have been correctly inserted and configured. I have not configured LDAP since we are still in LAB environment, the servers haven't been placed in a domain either.
a) No presence visible on my contacts
b) Cannot shift between DeskPhone and Softphone modes
c) Telephony, video and chat icons are grayed out
d) When I go to CUPC->Show server health, the Presence server is red and just says "Connecting".
e) When I surf to CUPS and go to User Mgmt->End User and click on the user the Internet explorer hangs. This is not a PC error since I get the same error on several PC:s running different OS and versions of IE
One thing I noticed in the Presence Troubleshooting Guide is on page 5 and step 3. It says: "Go to Application > Cisco Unified Personal Communicator > User Settings in order to verify that the device is the Preferred CTI Device in CUPS."
I have no such parameter, only 4 dropdown lists of which none contain information about Preferred device.
Assuming you're using CUPS 7.0.x, go to CUPS Admin > System > Security > Incoming ACL. Add an ACL with "address pattern" set to "ALL".
This should fixed most of your problem (if not all).
If you deal with CUPS/CUPC a lot, take a look at this book:
Thanx for the tip! Yes, I'm using CUPS 7.0 and I solved most of the problems just as your reply came in. But I did it with the help of an earlier topic on NetPRO. I entered "Dummy" information in the Digest Authentication and Associated PC fields for the End-user. I haven't seen anywhere in the documentation that these fields need to be filled out but it did the trick. Do you know why they have to be filled in.
But I am a bit curious about your solution? Does setting ALL on the ACL let all traffic through and fixes the problem?
Yes, you may solve this problem either way.
To understand it, you'll have to understand "Digest Authentication".
"Digest Authentication" is the authentication method of SIP protocol. Almost all SIP applications require "Digest Authentication", implicitly or explicitly.
Technically, there are two tiers of authentication before CUPC can connect to presence.
The first tier is user login, which happens on CUPC login window. You enter the username and password of CUCM end user, CUPC will connect to CUPS server via SOAP.
At this point, CUPC starts downloading configuration from CUPS.
With the downloaded configuration, CUPC knows the address of the SIP proxy and tries to connect.
At this point, a 2nd tier of authentication happens, which is "Digest Authentication".
If there's no digest credential configured on CUCM for the end user, this 2nd tier authentication would fail. You would get a "Invalid Credential" on CUPC "Show Server Health".
You might wonder:
1) Why wasn't I prompted for the 2nd authentication?
2) When the "Digest Credential" could be any dummy value on CUCM?
1) CUPS synchronizes database from CUCM. Hence, CUPS knows the "Digest Credential" of the end user. During CUPC logon, this information was passed from CUPS to CUPC silently. CUPC will use this information for the 2nd tier authentication.
2) Since CUPC would get whatever digest credential configured on CUCM, you could configure any dummy value on CUCM.
Another solution is to bypass the 2nd tier authentication at all, which is the "Incoming ACL" on CUPS.
Anything on the "Incoming ACL" will bypass the 2nd tier authentication. A "all" ACL matches anything, which means "bypass digest authentication" for all.
There were a 3rd option, which is turn off the "Authentication Module" in SIP Proxy service parameters.
Again, see my book at:
I'm having a similar issue. I'm able to get logged in to CUPC but every so often I can't switch to Deskphone control. When this happens I check the server health and it saying "Invalid Credentials" for the Deskphone. I am logged in to CUPC and on the CUPS I have an ACL for ALL in Incoming and Outgoing. If I rest the end user password, even back to what it was previously, it works. I saw in your blog where you said it normally happens with LDAP Authentication but I'm not using that or LDAP integrated. Any ideas as to why it does this?
No have I haven't because I wanted to see what others said first. I find it odd that if I reset the end user password, not the digest, then it works for a while. If I have to set the digest password then why does it work at all if I don't have one set and if I reset the end user password why does it fix it? I can't pin point exactly how long it takes it to break but it eventually does.
I'm open to do whatever I just want to see what other suggest. We are in the pilot/testing phase of this deployment so it's not a big deal right now.
Desk Phone control has nothing to do with Digest Credential or ACL. Digest Credential and ACL are used for SIP only. Desk Phone control uses CTI.
If you got "Invalid Credential" on desk phone control, that means CTIManager cannot authenticate the end user. To find out why, we need the following:
1) CUPC problem report (with "detailed logging" enabled)
2) CTIManager logs (with detailed level)
3) End user ID and DN (directory number).
Username and password are the same CtiGw and I can't recall the permissions right off hand. I just downed my servers for some maintenance but all of that should be correct. I had some bigger issues a few days ago that TAC took care of and we worked on that so it should be correct but I'll verify.
Again, "CtiGW application user" has nothing to do with CUPC.
"CtiGW application user" is for MOC only.