Is SimpleVoIP down?

We are investigating reports of issues with our Administration portal located at http://portal.simplevoip.us. We will provide updates as soon as we have identified the cause and impact of this event.

We are continuing to investigate this issue.

We are currently investigating reported issues affecting Call Center functionality. We have implemented a routing change as a potential mitigation and are monitoring its effectiveness while continuing to investigate the underlying cause. We will provide further updates as more information becomes available.

We have taken multiple steps to mitigate the reported Call Center issues and are actively monitoring system performance. Our team continues to investigate and address any remaining issues while working to ensure sustained stability. We will provide further updates as we continue to monitor.

Call Center service has been largely restored following our recent routing changes. We are continuing to investigate reports of intermittent instability and are actively monitoring service performance. We will provide additional updates as our investigation progresses.

We are currently working to apply a fix for the ongoing Call Center instability. This process involves rolling server restarts, which are not expected to impact phone service or call routing. We continue to monitor service performance closely and will provide further updates as we progress.

The patch has been successfully applied, and we have moved into monitoring. We are continuing to keep a close eye on Call Center service to ensure stability. Customers who continue to experience issues with Call Center functionality are encouraged to contact our support team.

Following the successful application of our patch and subsequent service restarts, Call Center services have remained stable with no further issues observed. We will continue routine monitoring and are marking this incident as resolved.

Yealink devices running older firmware versions (<v84) that fetched their configurations from affected web servers (roughly 10% between 10/16-10/20, 100% on 10/21) had their configurations wiped and could not reconnect to SimpleVoIP without manual intervention. The vast majority of Yealink devices are running newer firmware versions and were not affected.

## Impact  Yealink devices running older firmware versions \(<v84\) that fetched their configurations from affected web servers \(roughly 10% of check-ins between 10/16-10/20, 100% on 10/21\) had their configurations wiped and could not reconnect to SimpleVoIP without manual intervention. The vast majority of Yealink devices are running newer firmware versions and were not affected.    ## Root Cause  SimpleVoIP recently replaced some of our web servers in order to keep up to date on bug and security fixes. As part of that server replacement, we introduced an unintended behavior change that redirected unrecognized URLs to our index page, whereas they would previously have received a 404.  Yealink phones request some generic boot files \(e.g. /y000000000100.cfg\) before requesting their MAC-specific configurations. We supply everything via the MAC-specific config, so these generic requests are ignored. The old servers responded with a 404. After moving traffic to servers running the new OS/configuration, those requests returned HTML rather than a 404 or valid config documents.  Yealink firmware versions newer than v84 ignored these responses as invalid. Older firmware versions attempted to apply the HTML response as a config, found no valid config directives within the response, and blanked the running config, including the provisioning server directive, which prevented the phones from requesting a new config from SimpleVoIP after a reboot.  Factory resetting the phone would typically hit the Yealink redirect server, providing it a skeleton config with SimpleVoIP’s provisioning server URL to enable it to download its full config from us. Unfortunately, Yealink changed their redirect server infrastructure on October 1, 2025, making it inaccessible to older firmware versions and many EOL models. As a result, the same models impacted by the invalid generic config responses were unable to reconnect to SimpleVoIP without more significant effort \(providing a provisioning server URL via DHCP option 66 or manually updating phone configs individually\).    ## Remediation  ### Immediate  Our infrastructure team updated the running web server configs to respond with 404s to the generic config requests from these phones at around 6pm CDT Wednesday. This allowed the phones to boot normally when pointed to our provisioning server.  ### Near- to Mid-term  We will be updating firmware for these older devices to the latest firmware versions available. Some, like the SIP-T29G or SIP-T42G, never received a firmware release from Yealink that would have prevented this issue or allowed them to recover with a one-touch factory reset. Our Operations team will discuss replacement of these models with phones that are still receiving manufacturer updates.  It is common to encounter network issues \(usually firewall\) that may prevent phones from pulling the firmware we define in the device config. We’ll be making a concerted effort to notify customers proactively about devices that aren’t updating and working with them to get as close to 100% compliance as possible.  Our Engineering team will also be implementing some anomaly tracking within our monitoring system focused on config requests so that we can proactively detect any sudden changes to config retrieval.    ## Incident Timeline  2026\.10.16 17:00 UTC - Affected servers were entered into the available server pool serving a small percentage of config traffic. Bulk of traffic still handled by legacy servers.  2026\.10.17-10.20 - Isolated reports of devices not coming up after check-in.  2026\.10.21 05:00 UTC – Newer web servers take all traffic from legacy server pool, increasing percentage of requests handled by affected server.  2026\.10.21 23:00 UTC – Web servers are reconfigured to respond with 404s for generic config requests, allowing successful device config fetches.

Affected Algo, Poly VVX 150, 250, 350, 450, and PolyEdge 350 devices that requested their configuration from the affected server. Devices would receive a blank config and fail to connect to SimpleVoIP services until the device pulled a valid configuration from an unaffected server. Poly devices could recover with a reboot, whereas Algo devices needed manual intervention to restore the provisioning server URL.

## Impact  Affected Algo, Poly VVX 150, 250, 350, 450, and PolyEdge 350 devices that requested their configuration from the affected server. Devices would receive a blank config and fail to connect to SimpleVoIP services until the device pulled a valid configuration from an unaffected server. Poly devices could recover with a reboot, whereas Algo devices needed manual intervention to restore the provisioning server URL.    ## Root Cause  SimpleVoIP recently replaced some of our web servers in order to keep up to date on bug and security fixes. One of the new servers was missing configuration template files. A software bug in our config generator continued to build a configuration despite not having a template to build from, so Algo and certain Poly phone models requesting their configs from this server received an empty configuration containing just boilerplate. This wiped the SIP credentials and kept the phone from registering until a valid configuration replaced it.    ## Remediation  ### Immediate  Our infrastructure team restored the missing configuration template files to the server in question. Since Poly phones receive their provisioning server setting from a separate configuration file that wasn’t affected by this bug, a simple reboot was enough to tell them to request a new config, at which point they got a completed, valid config file. Algo devices needed to have their provisioning server URL configured either manually through the device UI or via DHCP option 66.  ### Near- to Mid-term  A patch to fix the partial config bug will be released after appropriate QA to prevent similar issues from reoccurring. We expect that to go live within the next week.  Our Engineering team will also be implementing some anomaly tracking within our monitoring system focused on config requests so that we can proactively detect any sudden changes to config retrieval.      ## Incident Timeline    2026\.10.16 17:00 UTC - Affected server was entered into the available server pool serving a small percentage of config traffic. Bulk of traffic still handled by legacy servers or healthy replacements.  2026\.10.17-10.20 - Isolated reports of devices not coming up after check-in. Reboots brought devices up in almost all cases.  2026\.10.21 05:00 UTC – Newer web servers take all traffic from legacy server pool, increasing percentage of requests handled by affected server.  2026\.10.21 19:45 UTC – Config templates are added to the affected server, healthy configs are served from this point on.