05-13-2010 12:02 PM - edited 03-15-2019 10:45 PM
Hi Folks,
Im deploying a CUPS solution with all features such as deskphone, conferencing, VM, LDAP etc.
The CUPS server version is 7.0 and the 7.0(1.13056).
Server health shows all green,system troubleshooter is fine without erros, all CUPC client features
are working perfectly. But however there is an weird issue with the status of the CUPC client.
1. All the CUPC clients when logged in take more than a minute to show status as available. And if
the user changes state it atleast takes 20 seconds for the presence info to be propagated to the
other clients.
2. But the problem is few of the clients when logged in status always show offline. If u try
to change the status manually u could not, the invisible status is checked in and could not
be unchecked.(But presence viewer in CUPS shows available)
3. The weird thing is the above status offline issue is intermittent and irrespective of the
client PC's.
4. But the presence viewer in the CUPS server always show the presence status perfectly for all
clients.
My understanding is that the presence info respective to the presence server is fine, but there looks to be a lack of communication,
excess delay might be heart beat problem a between the CUPS and the CUPC. CUPS and CUPC clients are in
the same lan and if i ping the CUPS server from the client PC the latency is 1 ms.
Any help regarding this issue would be gretly appreciated.
Solved! Go to Solution.
05-13-2010 01:00 PM
This has firewall written all over it. If the status selector is enabled but you cannot change the status in CUPC, it failed to self-subscribe to your presence. This happens using a SIP SUBSCRIBE or PUBLISH command which should receive a SIP 200 acknowledgement from CUPS. Your best bet is to run a packet capture on the PC and see when and if the SIP traffic is getting through. The SIP Workbench product may help you if you're not a SIP expert.
05-14-2010 03:01 PM
What's the IP address of CUPS and CUPC?
Was it 172.30.38.25 and 172.30.147.8?
From the packet capture, it looks like the client received the NOTIFY after 90 seconds.
To see if the delay was causing by the server, could you get the following?
1) Set the Presence Engine trace to "debug"
2) Set the SIP Proxy trace to "debug". Make sure you choose every option.
3) Start packet capture from server by using command "utils network capture file cups count 100000 size all"
4) receate problem
5) Press Ctrl-C on server to stop capture
Get Presence Engine logs, SIP Proxy logs, packet capture from server. Client side capture is optional. But if you could get it, that would be better.
Michael
05-13-2010 01:00 PM
This has firewall written all over it. If the status selector is enabled but you cannot change the status in CUPC, it failed to self-subscribe to your presence. This happens using a SIP SUBSCRIBE or PUBLISH command which should receive a SIP 200 acknowledgement from CUPS. Your best bet is to run a packet capture on the PC and see when and if the SIP traffic is getting through. The SIP Workbench product may help you if you're not a SIP expert.
05-14-2010 11:09 AM
thanks Jonathan. However i tried the sip workbench and i could see the capture to be similar for the user who could not connect and for the user who could connect on the same PC. But the user who could not connect was available after few attempts of exit and relogging in. This is completely weird. Pls find the attached files.
05-14-2010 03:01 PM
What's the IP address of CUPS and CUPC?
Was it 172.30.38.25 and 172.30.147.8?
From the packet capture, it looks like the client received the NOTIFY after 90 seconds.
To see if the delay was causing by the server, could you get the following?
1) Set the Presence Engine trace to "debug"
2) Set the SIP Proxy trace to "debug". Make sure you choose every option.
3) Start packet capture from server by using command "utils network capture file cups count 100000 size all"
4) receate problem
5) Press Ctrl-C on server to stop capture
Get Presence Engine logs, SIP Proxy logs, packet capture from server. Client side capture is optional. But if you could get it, that would be better.
Michael
05-15-2010 06:00 AM
Michael,
The ip address of the CUPS server is x.x.x.25(primary), x.x.x.x(secondary) and x.x.x.8 is the ip address of the CUPC. Im trying to get the other logs.
05-18-2010 05:24 AM
Michael and others,
Thanks everyone for your suggesstions and support. The issue is resolved. Sip inspection was enabled by default on one of the LAN core 6500 switch. We are already aware of the fact that we need to disable sip inspection but there was some miscommunication in audit with the team which manages the 6500. Once again thanks for your support.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide