Online/offline status is base on connection to XMPP.
May we request for you to please check your XMPP connection between RControl.exe application and XMPP server via Tcpview.exe utility: TCPView for Windows - Sysinternals | Microsoft Learn
(see attached screenshot)
Check if sent and received packets appear and connection with XMPP server is stable (not terminating in time)
Our XMPP servers addresses are 18.196.72.222, 18.196.138.4, 18.197.8.210
HI @Anna_C not sure why this matters if portal and desktop app both use XMPP for determining online status?? What’s the difference in the portal and desktop app for online status?
Follow up - Not all clients show offline just some do, this issue is something with desktop app in my opinion not XMPP since portal sees them online and desktop app is seeing them offline and my guess is that you would use the same servers for both the portal and app
I have this issue as well and regularly. Some clients will be fine others will be offline even though they aren’t. There is no firewall on the any computer. If I restart the computer trying to initiate the session then they will show up as online. Its getting kind of annoying and bothersome to the point I’m looking at getting away from using that feature.
We do have the same problem. After half an hour some endpoints show up in the desktop app, but connecting fails in most of the times. This is with different networks/locations. Sometimes running the “Restart the Communication Client Script” helps, but not always.
We are still experiencing the same symptoms too. Today is pretty good but last night was bad, 8pm-1am Eastern Time (UTC -4) then I called it quits, just letting you know it’s not just 1 person seeing these issues still.
Possible reasons for remote issues would be blocked IPs and ports by a network firewall, Portal Server assignment (account set up on incorrect server instance / US UK), Third-Party Security Softwares, incompatible OS environments, and least would be network connectivity. There might be other possible reasons too why remote connections might fail multiple times or not even progress at all. These latter ones would require log gathering from the affected device and other private information from the portal account that can only be collected privily through a support ticket.