We have experienced similar issues.
Additionally, and possibly related, we have had calls put on hold, the outside end hangs up. this should free up the line, BUT it does not. It continues to remain on hold and occupies the line.
We have to go to the line and end it.
Is our account being charged for these minutes?
@Brandon - I've seen this issue happen in the past for customers who don't have their
routers configured correctly. But Brandon, I think you've already verified this recently with us, correct? If so, I recommend
opening a web case and putting those call samples in the case. Remember that call samples will need to be within 24 hours and must include the Date, time, called to, called from, and result. If you open a case, please provide me with the case number here.
I'm not sure. I'm not really worried about the minutes. My concern is that I have reps available but their line is considered 'busy', which means callers cannot get through. Not to mention the two callers I mentioned think we've left them on hold and forgotten about them.
I guess what I am getting at is: Did any other users report a similar issue on Friday? Around 6pm EST? I searched the forum and didn't see anything, but I wanted to inquire further. If nobody else had the issue then perhaps it is a fluke.
Gah. Last evening I configured the router with the recommended port triggering and, unfortunately, this morning I still see issues with HUD/presence status showing incorrectly. My router configs are attached via a screenshot.
NOTE: The port triggering information provided to me by Nathan on 6/03/2016 (via private message) and the ports specified in the
official support answer on 6/07/2016 differ slightly.
This reply was created from a merged topic originally titled desktop app HUD - Version 8.1.1 Issues with Presence between Desktop Apps. Hi,
Are there any known issues with the desktop app version 8.1.1 and presence between desktop app clients?
The status doesnt change to Busy or on a call, so calls are still routed as the system sees all clients as available.
Does anyone else have this issue?
Many thanks
Jon
This reply was created from a merged topic originally titled Presence on deskphone shows on a call, desktop app shows available. We have a couple of users whose phones are showing on other users' desk phones as on a call. However, they are not and their desktop presence also shows available. When you attempt to call their extension, it sends you to another user's extensions.
This reply was created from a merged topic originally titled Presence: user still showing "Available" when on an incoming call.. When picking up an incoming call from the auto-receptionist, the user still shows available in Presence, as well as when retrieving a call from Park.
Presence only shows you are on a call when taking an incoming call on your direct line, a transferred call or when you are on with another RC user.
We would like for that user to show as on an active call in presence ANY TIME they are on the phone.
Is this an RC issue or a settings issue?
Hello All,
I wanted to provide the following information in hopes to help resolve the HUD issues on the softphone. The new versions of the softphone use a new set of IP subnets to signal presence for the HUD. In order for the HUD to work correctly you need to make sure that your router or firewall will allow traffic both inbound and outbound from the below noted IP addresses over the ports listed on our network requirements page.
Check for Network Updates here:
QoS How do I troubleshoot Call Quality issues? Network requirements?54.249.82.128/26
54.236.3.128/26
54.241.191.192/26
54.246.196.128/26
54.207.127.192/27
37.58.79.160/27
198.11.216.98/27
5.153.35.160/27
50.22.5.112/28
54.175.63.64/26
54.93.127.192/26
54.209.255.64/26
54.241.191.64/26
54.219.189.192/26
52.4.63.128/26
54.233.127.192/27
54.219.189.64/26
54.175.191.192/26
54.250.252.0/26
54.171.191.192/26
54.93.254.192/26
I hope this helps to resolve the problems.
We're currently running RC Windows vers 8.2.1, and noticed that the new DND presence status appears as "Busy" on everybody else's HUD. Just opened a case regarding this issue, but still noticing some presence glitches as well.
We had a call come through the call queue earlier today which I answered, and after I ended the call, I noticed that one user was still showing there was an incoming call from that same number. Persisted for a few minutes before it corrected itself.
Kim (and RC Team),
I feel like I've dealt with so many people, between the support community, reps on the phone, etc and I've provided a lot of information about the problem, but it's not all in a single place. So, to help your tech folks locate the issue I am giving you a single summary of the issue that has been discussed in multiple posts and tickets.
I want to start by reminding you that I own a software company and I write software architecture, so I have expertise that is relative to the problem. I am only pointing this out because, as I am sure you know, most people lack this expertise and can often confuse a real issue with their own user error.
Our Setup
I have four employees. 3 of the 4 employees work in the office every day, 1 works remotely most days. For those in the office, they have a Polycom desk phone which they use to make and receive calls. Each employee also has the desktop app running, but this is primarily to quickly set their presence status and it makes it easier to track other user's presence. The remote user does not have a Polycom desk phone, she uses the desktop app to make/receive calls and has a Polycom headset. All users have Windows 10 as their OS.
Issue Summary
There are many variations to the issues we experience, but most often the issue is the presence/status of one or more users isn't accurately reflected. That could be on the HUD, on the desk phone itself and, sometimes, on both. Examples of this are:
- A user is shown as on a call or on hold when they are not
- A user shows as available but they are actually on a call
To be clear, the above examples can happen on the HUD
OR the desk phone, and sometimes
both (at the same time). It's completely random, and some days the issue may even switch between the two. For example, today our desk phones are showing presence for each user correctly while the HUD is completely off, absolutely incorrect 100% of the time. However, it's quite possible that at some point today the desk phones will show inaccurate information and the HUD will be the accurate source. It's also possible that, at some point today, both will accurately display user presence. It's a crap shoot, we never know. As I write this post I am watching my HUD as it shows one user on a call and another user has an incoming call, yet the desk phone correctly shows that neither user is on a call right now.
Variation 1A variation of the issue described is when an inbound call is answered yet continues to show as ringing other users for a period of time. Example: An inbound call from 555-555-5555 simultaneously rings three users. User 1 accepts the call and is connected. The HUD will usually (correctly) show that user 1 is on the call with that caller. However, the HUD will continue to show the same caller as an incoming call to user 2 and user 3. There are times when this lasts a minute or two, and other times it may last 20 minutes or more. Ultimately it doesn't affect their "true" status since they can still accept new incoming calls, but it can be confusing when you look at the HUD.
Variation 2 (More Severe)
So far the issues I have described are more of an annoyance than anything. While their presence may not be accurately displayed the RC system still knows their "true" status, allowing them to accept calls if they are truly available. However, with this 2nd variation of the issue their true status can be incorrect, which means that available users are not receiving inbound calls. This is, obviously, a very big deal because we could have potential customers in a call queue, and reps available, yet the reps don't even know that there are inbound calls. Most often we find out about this issue when we receive a voicemail during office hours. With reps available we don't expect to see a voicemail come in and, when we do, it usually has something to do with this issue.
To clarify, my definition of "true" status is the status RC shows for each user in a specific queue in the "Member Availability" screen (screenshot attached). In this particular variation the user will show as busy or unavailable when they are, in fact, available. By 'available' I mean their actual status is "Available", they are not on a phone call and they are accepting queue calls.
Troubleshooting
We've done a lot of troubleshooting here and have already completed the obvious tests and potential fixes. Most recently I was here overnight and configured the router with the recommended port triggering and QOS (per
this resource).
Observations
As someone who understands software I am consistently looking for patterns. 98% of the time software issues have
something in common; locating that commonality will typically give clues as to the root cause. This issue, and the many variations, have been ongoing for a very long time. As I write this I can confirm the following:
- It happens at random. There are no patterns in terms of the day, time, call volume, number of users online or anything similar. It happens when it happens, there does not appear to be a specific trigger. There are days, sometimes maybe even weeks, when we have no issues at all. Conversely, there are times when it happens constantly
- Whether it is the HUD (desktop app), desk phone or both is also random. There isn't a pattern
- No other applications, computers, connections, etc are affected. Everything else (e.g. the Internet, Internet connection, local PC's, software, etc) all operate normally when these issues occur
- I am 100% certain that the cause has nothing to do with the router, Internet or the configuration of either. I know this because the employee who works remotely experiences many of the same issues at the exact same time. Considering she is not on our network and using a different ISP this means that it cannot be network related. This point can be proven by Nathan's support response in which he verified that a remote user cannot be affected by our internal network under the conditions I described
The Root Cause
I am not a RC engineer and I don't know how your software works. So I can only hypothesize as to the root cause, the one thing the the majority of the issues have in common: the syncing of user presence.
I've spent most of my day really exploring this issue. I figure today is a great day for it because it's been consistent and, as any developer will tell you, it's always best to troubleshoot as the issue is occurring.
Anyway, I've talked with my employees about the variations of the issues to see if anything they have experienced helped me understand it better. My office manager, Kayla, said something that really grabbed my attention. She was talking about the sync issues and how, at times, it appears that the presence of two users were somehow intertwined. For example, user 1 is on a call and is the only user on a call, this shows correctly on the HUD. While user 1 is on the call User 2 makes or accepts a new call. Sometimes, when this happens, user 1 appears to be on two calls while user 1 shows as available. When user 2 hangs up the HUD immediately shows user 1 as being on one call. I found that interesting.
As I thought about this further, and the sync issues, I started to think about what could cause such confusion. Then it hit me: cache. What if the RC desktop app is somehow confusing current data with cached data, or something similar? As a desktop application it stores all kinds of data so I assumed this must be possible, especially when you consider how much is going on behind the scenes.
So, I explored the desktop app and found the 'Purge Data' button (cog icon > support tab). I clicked it. When the desktop app reopened I signed in and, believe it or not, the problem was resolved - Immediately both the HUD and desk phone were synced. My initial thought was that this would only affect me at my local workstation because, afterall, I only purged my local application data. But, inexplicably, it resolved the problem for everyone, even my remote employee.
Now, is this a real solution? I doubt it. It's only been 30 minutes since this happened and, while everything is still working correctly, I am guessing the problem will come back shortly. I also find it very odd that the purge data on my local computer fixed the issue for everyone; that will definitely need to be explored further by someone at RC.
Hi Kim,
This thread talks about a few issues, but today I'm back to the original issue where a caller that was put on hold appears to be disconnected yet, somehow, remains on hold. Basically, the exact same thing I described in the original post on this thread. It first happened last Friday and hasn't happened since then, until just now. I have a user who is not on a call yet RC thinks she is. My guess is that, just like the previous occasions, the caller that appears to be on hold really is on hold. Is there a way to force the line to disconnect from a call?
Please get with Sean, the T3 agent working on your case. He sent you an e-mail yesterday.
We hope to have this fixed in an upcoming release.
If others need to open a case, please put this in the Subject: PHON-14024 Desktop App receives incorrect line status for displaying in HUD
A couple of coworkers and I have updated to version 8.3.4, which I was hoping would resolve the issues with displaying presence errors. Unfortunately, it doesn't seemed to have fixed the issue. The HUD for all of the other users in the office (including the users on 8.2.1), show that I am currently on a call, even though I'm not. Furthermore, I wasn't even the one who answered that call, yet it shows I still have an active call with that number.
For one of the users on 8.3.4, I logged her out & closed RC Desktop, then deleted the two folders in Appdata>Local>RingCentral, then logged her back in. No change. I then did the same for myself. Again, no change, other users are still showing I'm on that call (which I never answered), even after 40 minutes have passed since the call ended with another user.
Image below is HUD from Ext.402, running vers RC Windows, 8.3.4
Image below is from my call log, showing that I missed that call. Call was actually answered by Ext.402, parked in Ext.104, picked up by Ext.404.
Hi. Last Monday we started having issues with presence on the Blind transfers. When the receptionist transfers a call from a customer to a user using the blind transfer, the call reach the user but the presence on the HUD for the windows app and the deskphone do not sync. It shows the user is still available. Anybody is having the same issue?
Hi Kim. You are correct. But shortly after configuring the router last time around I removed the settings because I found some conflict. I actually planned to try again this week, I am in the office overnight for a software release and planned to update the router configs again at that time.
But, the issue I described is really unique, I wonder if it could be something else. Considering we've had RC for more than 5 years and I've never had this issue. Plus, it affected an in office employee and a remote employee, both at the exact same time. I found that a bit coincidental to be just router settings.
Seems like this is an old issue but we are struggling with the HUD status not reflecting the app status (which appears to be accurate) for our users. Why don't they match?
