It has now been roughly 18-mos and the issue described below has not been fixed. GoTo Support seems to have given up and sent me here, suggesting that the development team closely monitors the community forum more than the actual support tickets. Claims of the problem being fixed have not been accurate. In short, voicemails do not delete properly.
- Polycom VVX 250
- Android phone app
When a voicemail is received, the expected actions occur. The notification light on the Polycom appears, an email notification arrives (with the voice-to-text message), and the GoTo Connect app shows the voicemail and voice-to-text. Deleting the voicemail (VM) is where everything goes sideways. Here are the most common behaviors:
Initial deletion from the Android phone app
Voicemail and text removed from the Android device
Some minutes later the notification "may" reappear as a new voicemail and unread message, but there isn't a message to view or voicemail to listen to. This is not consistent behavior.
The notification light on the Polycom remains flashing for up to a few hours
Other times the message notification will never disappear without manually clearing it from the Polycom one or more times.
Initial deletion from the Polycom
Voicemail removed from the device
Notification light returns after a few minutes
Voicemail may or may not be removed from the Android app --- and usually takes a few hours
Checking the voicemail and nothing is there---other than the notification.
This is repeatable, meaning I can delete the message multiple times and it will reappear.
Deletion from ALL devices (removing the voicemail from both the Android app and Polycom)
The notification light on the Polycom will return after a few minutes
"Sometimes" it will actually return the notification to the Android app
There won't be any message to read or listen to on either device, just the notifications that there is a message available
After multiple deletions over a period of time, the notifications will finally disappear
Before this problem developed simply deleting the VM from either the Polycom OR the app, and a few minutes later it would be gone from the other device---and not return.
I have provided numerous call examples to GoTo Support, providing the phone number, time of call, time the call was deleted, when the notifications reappeared, etc. I'd be told that they see the problem and have corrected it, only to test and see either a minor change in the behaviors described above or no change at all.
The Android app has been uninstalled/reinstalled numerous times (clearing cache and data before/after, and every other sequence. This has occurred on two different Android phones (S9+ and S22 Ultra). The Polycom has been restarted, cleared, sent updates, etc. The behavior remains the same whether VPN is active or disabled. Rebooting network appliances (which occurs weekly by default anyway) has no effect--and all appliances and applications have the latest software and firmware.
I happen to have a degree in networking (can program Cisco appliances) that I don't use, so the comments below are my thinking out loud regarding the configuration of various network appliances. I suspect this is a data configuration or data connection issue (with GoTo Connect hardware or a system or account configuration problem), where either the cache at the server/cloud level is corrupted or unsuccessfully trying to overwrite. Because it used to work just fine, something had to change to create these behaviors. A latency or packet loss issue due to a faulty cable or other physical connectivity issue is possible, but should also highlight itself elsewhere. Open, blank lines at the end of a configuration file can cause problems with certain devices or applications. Since I do not know if others are experiencing this issue, additional diagnostics are required to see if it is limited to specific accounts, connections, or particular pieces of hardware. Incorrectly configured account settings are another possibility. For example, the configuration between the VoIP appliance(s) and those appliances handling VM. These could include a search for packet loss, a firewall configuration, routing configuration (back route), etc.
Since I do not have access to GoTo Connect's hardware and associated configurations, all I can do is offer the behaviors and a few suggestions and leave the rest of the diagnosis and correction to the paid engineers. However, it has been OVER A YEAR and this is not fixed!