We have a CUPS integration with CUCM, however none of our CUPC can change to an online state.
when a user changes state to online the state does not change.
also presence viewer also states that other users can see the user as available until they log in and cannot see the user online the presence viewer test then says that they are unavailable.
Deskphone calling is working correctly.
Logon Server, Precense Desk Phone, Voicemail and LDAP are all connected and succesful.
connection down bottom of CUPC is connected.
Has anyone experienced anything similar to this? Any help would be appreciated.
Solved! Go to Solution.
Just to clarify, you have the 'Presence' green lighted in the server health screen? If not, this is usually down to missing 'Digest Credentials' on the end user.
What version are you running?
Presence is green lighted in the server health screen.
I have also tested with 4 different users, all with the same issue on different PC's
We are running version 22.214.171.12400-18
Are you running LDAP sync to your CCM? If not, check the user ID in LDAP is matching the user ID in CCM exactly (i.e. case sensitive).
If you take a good user to a PC that is unhappy, do they work OK? And a bad user to a good PC, does the error follow the user?
Yes we are using AD to sync our CCM, We are also using phone numbers to log in rather than usernames.
unfortunately all users are unhappy right now, all users with the same issue as originally described.
I take it you've made no admin changes?
Might be time to start looking at the server logs...
Please do the following:
1) Exit CUPC (make sure it was exited).
2) Start packet capture on the CUPC computer.
3) Launch CUPC and log in.
4) After CUPC stablized, stop packet capture.
In packet capture, filter SIP packets. You should see the following sequence:
Thanks for the information, I am seeing all of the outgoing packets, Also the subscribed packets also differ between 2 and 3 being sent.
Aaron, that is correct, no admin changes have been made.
"I am seeing all of the outgoing packets" -- that means you're NOT seeing the incoming NOTIFY?
If that's the case, it's most likely a network issue.
To further prove that, you need to do packet capture on client and server side for the same time frame. You'll see server sent NOTIFY, but client never received it.
Command line to do packet capture on server:
utils network capture file cups count 100000 size all host all 192.168.1.100
192.168.1.100 is the IP address of CUPC client.
To stop capture, press "Ctrl-C". To get the file use command below:
file get activelog platform/cli/cups.cap
Can you do the following?
1) Enable detailed logging from CUPC > Help.
2) Exit CUPC
3) Start packet capture
4) Launch and log into CUPC
5) Wait for 2 minutes
6) CUPC > Help > Generate Problem Report
7) Stop packet capture.
Attache problem report and packet capture here. We can take a look.
From server packet capture, you can see that the server was trying to send NOTIFY to client but failed (packet #107).
From client packet capture, client never received NOTIFY.
Those two capture files should be a good starting point for network engineer to troubleshoot.
At this point, it's not a CUPC/CUPS issue.
We are now receiving the SIP NOTIFY packet when we sign onto the CUPC client and when we change our status.
We can change our status to away, DND, and invisible, however we can't change to online and cannot see other users status.
It seems that we are only receiving SIP NOTIFY packets intermittently.
Have you seen anything similar to this before? There is nothing in our infrastructure denying these packets.
The proof is very obvious -
We have server capture and client capture. From server capture, we can see NOTIFY bening sent. From client capture, we don't see it.
If a packet left its source but didn't arrive on destination, what could it be?
I cannot tell you where the problem is. But I can tell you the problem is not on CUPS/CUPC.
Are there any specific commands on the ASA55XX series which would be dropping specific SIP packets other than security policies specifying to do this.
We have SIP inspection enabled, but no ACLS or policies specifying for this to be blocked.
If you looked at CUPS_CLIENT.pcap, you'll see that those NOTIFY was from the client to the server.
What we are missing is the NOTIFY from the server.
It's still the same problem as before.
This is happening to us also
I have unassigned users and
then reassign them and it seems to work some of the time but why they go invisible after awhile still baffles me
Has anyone seen where a users working for a week then not
This issue was caused by SIP inspection on FWSM dropping the packets between CUPS and CUCM
Maybe try that.