Troubleshooting

Common error messages and codes received with the application or results:

  • There was a network error when processing the key - This is caused when the application cannot communicate with 8x8 servers over TCP port 443 (HTTPS). Check your access rules, proxy server or if you are running a client VPN, disable the VPN and restart the application.

  • Open a Program From Unidentified Developer on MacOS. If you receive this error message, see Open a program from unidentified developer on MacOS.

Error codes and explanations

Below is a list of all error codes and explanations, with possible resolutions.

All tests that were performed ran Successfully, and we found no errors.

When using a voice Only VLAN (a Virtual Lan with only Hard Phones and no computers on it), 8x8 recommends that you set the 8x8 GTMs (8.28.0.9 and 192.84.18.11) as the Primary and Secondary DNS servers in the VLANs DHCP Scope. An alternate option is to implement conditional forwarding of 8x8.com and packet8.net on your local DNS servers to 8.28.0.9 and 192.84.18.11, which are 8x8's DNS servers. It is not recommended to set conditional forwarding on your Data VLAN and/or if you have only one network.

We see that ALG is currently enabled on your edge firewall or on your ISP gear. 8x8 recommends that ALG be disabled on all your network gear, as it is known to cause the 8x8 solution to not perform correctly. For more information on ALG and possible solutions for disabling, see our ALG help page.

We did find that Fragmentation may not be supported by your edge device. In rare situations, signaling packets may become extremely large and require to be fragmented. If fragmentation is not supported, there will be a loss of audio. 8x8 Recommends that Fragmentation be supported by all network equipment, including routers. 8x8 also recommends that your MTU be set to 1500 on all networking gear.

Some of the required ports (HTTP/80) are being blocked by your firewall, and there are 2 options to resolve this issue:

-- OR --

  • An easy but secure method is to make sure that there is no blocking of any ports required by 8x8 is to open any-to-any ports from your internal network to the 8x8 data center subnets (outbound ports only).These subnets are available in the technical requirement document.

Some of the required ports (HTTPS/443) are being blocked by your firewall, and there are 2 options to resolve this issue:

-- OR --

  • An easy but secure method is to make sure that there is no blocking of any ports required by 8x8 is to open any-to-any ports from your internal network to the 8x8 data center subnets (outbound ports only).These subnets are available in the technical requirement document.

Some of the required ports (8443) are being blocked by your firewall, and there are 2 options to resolve this issue:

-- OR --

  • An easy but secure method is to make sure that there is no blocking of any ports required by 8x8 is to open any-to-any ports from your internal network to the 8x8 data center subnets (outbound ports only).These subnets are available in the technical requirement document.

Some of the required ports (SSL) are being blocked by your firewall, and there are two options to resolve this issue:

-- OR --

  • An easy but secure method is to make sure that there is no blocking of any ports required by 8x8 is to open any-to-any ports from your internal network to the 8x8 data center subnets (outbound ports only).These subnets are available in the technical requirement document.

We found that all NAT tests FAILED. Review your network edge device to ensure that all ports are open and a valid gateway is provided.

Your phones are not able to sync with the following time servers time.apple.com or time.windows.com. We recommend that you enable access to these time servers or reference 8x8's time servers at ntp.packet8.net. These servers are used to establish the proper time on your pc and used in the registration process for security purposes. As an alternative, you may provide your own timeserver to this device.

Your phones are not able to sync with the following time servers ntp.pool.org or time.windows.com. We recommend that you enable access to these time servers or reference 8x8's time servers at ntp2.packet8.net. These servers are used to establish the proper time on your phone and used in the registration process for security purposes. As an alternative, you may provide your own NTP server via DHCP Option 42.

Your phones are not able to sync with the following time servers ntp.pool.org or time.windows.com. We recommend that you enable access to these time servers or reference 8x8's time servers at ntp.packet8.net. These servers are used to establish the proper time on your device and used in the registration process for security purposes. As an alternative, you may provide your own NTP server via DHCP Option 42.

Some of the required ports are being blocked by your edge firewall OR endpoint security software, and there are 2 options to resolve this issue:

-- OR –

  • Our recommendation is to create an "Any to 8x8" rule in your firewall. The is a highly secure action as it is only opening outbound traffic towards a known destination (our 8x8 data center(s)). The list of our subnets is listed in the technical document previously supplied, or you may even simply use packet8.net and 8x8.com domains. Some of the required ports are being blocked by your firewall, and there are 2 options to resolve this issue. Explicitly open these ports in your firewall as per the technical requirement documents.

We did find an issue in the Ping/Time portion of the Media test, and this took a higher than acceptable amount of time to run.

We did find that there was Packet Loss that was higher than our recommended levels. We suggest that you investigate the local network to make sure there are no Congested Links or Bottlenecks in the local network. If they are identified, try to remove them or increase the bandwidth at that point. Another option that is highly recommended is to implement Quality of Service (QoS) to give priority to your voice packets. In rare conditions, older firmware or edge equipment may cause packet loss due to older firmware or performance limitations. We also recommend running a 3rd party utility called PingPlotter. We use this free trial application to help pinpoint where packet loss is being introduced into the route from your location to our data center. For more details, see How to use PingPlotter for network troubleshooting.

We did find that there was a jitter that was higher than our recommended levels. We suggest that you verify the QoS settings of the company network. If the QoS has not been configured or improperly set up, voice packets will not be receiving the proper priority. This will result in missed or discarded packets. Audio calls will then be subjected to high levels of jitter, degrading the voice quality. If the QoS settings are correct and network traffic is at its usual levels, there should not be any significant jitter.

Jitter buffers are not recommended, Although the size can be increased up to a point. Generally, they are only effective for delay variations of less than 100 ms, and even then, deterioration in quality may be easily noticeable to users. There are various tools available that can be used by experts to isolate jitter sources and remove them. Therefore organizations should try to identify the sources of jitter on their networks instead of relying on jitter buffers.

We did find that there was Latency that was higher than our recommended levels. In most cases, latency is introduced by a congested network or a carrier issue. 8x8 suggests that you open a ticket with your carrier to have their network reviewed if you are suffering from latency issues. Prioritizing VoIP traffic over the local network (and, if possible, the WAN) will improve latency and jitter issues as well. We also recommend running a 3rd party utility called PingPlotter. We use this free trial application to help pinpoint where the latency is being introduced into the route from your location to our data center.

We noticed that the Geo Routing, as determined by your DNS Server, would be using a less than optimum route, which could impact your voice quality. When using a voice Only VLAN (a Virtual LAN with only hard phones and no computers on it), 8x8 recommends that you set the 8x8 GTMs, 8.28.0.9 and 192.84.18.11 as the Primary and Secondary DNS servers in the VLANs DHCP Scope. An alternate option is to implement conditional forwarding of 8x8.com and packet8.net on your local DNS servers to 8.28.0.9 and 192.84.18.11, which are 8x8's DNS servers. It is not recommended to set conditional forwarding on your Data VLAN and/or if you have only 1 network. If your network only consists of a single line (you are not using VLANs), 8x8 can set the DNS of your hard phones to the GTMs.

There was a general error in the Latency Test. Review and re-run the test.

We did find that the number of tests with Latency is between 89 and 75 percent, which is higher than our recommended levels, OR there were one or more tests that exhibited latency greater than 100 ms. You will still be able to make and receive calls, but at times the audio quality will be lower than normal. We suggest that you investigate the local network to make sure there are no Congested Links or Bottlenecks in the local network. If they are identified, try to remove them or increase the bandwidth at that point. Another option that is highly recommended is to implement Quality of Service (QoS) to give priority to your voice packets. In rare conditions, older firmware or edge equipment may cause packet loss due to older firmware or performance limitations.

We did find that Jitter is between 89 and 75 percent, which is higher than our recommended levels. You will still be able to make and receive calls, but at times the audio quality will be lower than normal. We suggest that you investigate the local network to make sure there are no Congested Links or Bottlenecks in the local network. If they are identified, try to remove them or increase the bandwidth at that point. Another option that is highly recommended is to implement Quality of Service (QoS) to give priority to your voice packets. In rare conditions, older firmware or edge equipment may cause packet loss due to older firmware or performance limitations.

We did find that the number of tests with Packet Loss is between 89 and 75 percent, which is higher than our recommended levels, OR there were one or more tests that exhibited packet loss greater than 2%. You will still be able to make and receive calls, but at times the audio quality will be lower than normal. We suggest that you investigate the local network to make sure there are no Congested Links or Bottlenecks in the local network. If they are identified, try to remove them or increase the bandwidth at that point. Another option that is highly recommended is to implement Quality of Service (QoS) to give priority to your voice packets. In rare conditions, older firmware or edge equipment may cause packet loss due to older firmware or performance limitations.

We encountered a General Failure, and we are looking into this now.

There was an insufficient number of Media Tests ran to get a good overall picture. We recommend running for the suggested number of Media Test Runs.

DHCP Option 66 is enabled. Disable this option in your DHCP Scope.

DHCP is disabled on this interface, unable to verify DHCP is functional and if Option 66 is disabled.

Invalid results format possibly used an older version of the test.

Test was aborted.

Some of the required CC TCP ports are being blocked by your firewall. There are 2 options to resolve this issue:

-- OR –

  • Our recommendation is to create an "Any to 8x8" rule in your firewall. The is a highly secure action as it is only opening outbound traffic towards a known destination (our 8x8 data center(s)). The list of our subnets is listed in the technical document previously supplied, or you may even simply use packet8.net and 8x8.com domains.

Some of the required UC TCP ports are being blocked by your firewall, and there are 2 options to resolve this issue:

-- OR –

  • Our recommendation is to create an "Any to 8x8" rule in your firewall. The is a highly secure action as it is only opening outbound traffic towards a known destination (our 8x8 data center(s)). The list of our subnets is listed in the technical document previously supplied, or you may even simply use packet8.net and 8x8.com domains.

Some of the required CC TCP ports are being blocked by your firewall, and there are 2 options to resolve this issue:

-- OR –

  • Our recommendation is to create an "Any to 8x8" rule in your firewall. The is a highly secure action as it is only opening outbound traffic towards a known destination (our 8x8 data center(s)). The list of our subnets is listed in the technical document previously supplied, or you may even simply use packet8.net and 8x8.com domains.

Some of the required UC TCP ports from port 8000 are being blocked by your firewall, and there are 2 options to resolve this issue:

-- OR –

  • Our recommendation is to create an "Any to 8x8" rule in your firewall. The is a highly secure action as it is only opening outbound traffic towards a known destination (our 8x8 data center(s)). The list of our subnets is listed in the technical document previously supplied, or you may even simply use packet8.net and 8x8.com domains.

Some of the required CC TCP ports are being blocked by your firewall, and there are 2 options to resolve this issue:

-- OR –

  • Our recommendation is to create an "Any to 8x8" rule in your firewall. The is a highly secure action as it is only opening outbound traffic towards a known destination (our 8x8 data center(s)). The list of our subnets is listed in the technical document previously supplied, or you may even simply use packet8.net and 8x8.com domains.

Some of the required UC UDP ports are being blocked by your firewall, and there are 2 options to resolve this issue:

-- OR –

  • Our recommendation is to create an "Any to 8x8" rule in your firewall. The is a highly secure action as it is only opening outbound traffic towards a known destination (our 8x8 data center(s)). The list of our subnets is listed in the technical document previously supplied, or you may even simply use packet8.net and 8x8.com domains.

Some of the required CC UDP ports are being blocked by your firewall, and there are 2 options to resolve this issue:

-- OR –

  • Our recommendation is to create an "Any to 8x8" rule in your firewall. The is a highly secure action as it is only opening outbound traffic towards a known destination (our 8x8 data center(s)). The list of our subnets is listed in the technical document previously supplied, or you may even simply use packet8.net and 8x8.com domains.

Some of the required UC UDP ports from port 8000 are being blocked by your firewall, and there are 2 options to resolve this issue:

-- OR –

  • Our recommendation is to create an "Any to 8x8" rule in your firewall. The is a highly secure action as it is only opening outbound traffic towards a known destination (our 8x8 data center(s)). The list of our subnets is listed in the technical document previously supplied, or you may even simply use packet8.net and 8x8.com domains.

Bufferbloat was above 100 ms, resulting in slower network performance and voice quality issues.

We detected that there is a possibility of the use of a VPN, Proxy Server, is a Virtual Host or advanced security software that interfered with the normal selection of an interface. The default PC route was then used for this several tests. We recommend that all VPN, Vitalization, Etc. be disabled for the test. If you are using a Proxy server, 8x8 does not support proxy servers and will need you to set ALL 8x8 traffic to bypass the proxy server.

We did find that there was Packet Loss that was higher than our recommended levels. We suggest that you investigate the local network to make sure there are no Congested Links or Bottlenecks in the local network. If they are identified, try to remove them or increase the bandwidth at that point. Another option that is highly recommended is to implement Quality of Service (QoS) to give priority to your voice packets. In rare conditions, older firmware or edge equipment may cause packet loss due to older firmware or performance limitations. We also recommend running a 3rd party utility called PingPlotter. We use this free trial application to help pinpoint where packet loss is being introduced into the route from your location to our data center.

We see that ALG is currently enabled on your edge firewall or ISP gear. 8x8 recommends that ALG be disabled on all your network gear, as it is known to cause the 8x8 solution to not perform correctly. For more information on ALG and possible solutions for disabling, see our ALG help page.

We see that ALG is currently enabled on your edge firewall or ISP gear. 8x8 recommends that ALG be disabled on all your network gear, as it is known to cause the 8x8 solution to not perform correctly. For more information on ALG and possible solutions for disabling, see our ALG help page.

We see that ALG is currently enabled on your edge firewall or ISP gear. 8x8 recommends that ALG be disabled on all your network gear, as it is known to cause the 8x8 solution to not perform correctly. For more information on ALG and possible solutions for disabling, see our ALG help page.

We see that ALG is currently enabled on your edge firewall or ISP gear. 8x8 recommends that ALG be disabled on all your network gear, as it is known to cause the 8x8 solution to not perform correctly. For more information on ALG and possible solutions for disabling, see our ALG help page.

We noticed that the Geo Routing, as determined by your DNS Server, would be using a less than optimum route, which could impact your voice quality. When using a voice Only VLAN (a Virtual Lan with only Hard Phones and no computers on it), 8x8 recommends that you set the 8x8 GTMs (8.28.0.9 and 192.84.18.11) as the Primary and Secondary DNS servers in the VLANs DHCP Scope. An alternate option is to implement conditional forwarding of 8x8.com and packet8.net on your local DNS servers to 8.28.0.9 and 192.84.18.11, which are 8x8's DNS servers. It is not recommended to set conditional forwarding on your Data VLAN and/or if you have only 1 network. If your network only consists of a single line (you are not using VLANs), 8x8 can set the DNS of your hard phones to the GTMs.

Skipped one of more data centers.

We see that use of Google (or other caching DNS Server) is in use, and this is not recommended by 8x8. When using a voice Only VLAN (a Virtual Lan with only Hard Phones and no computers on it), 8x8 recommends that you set the 8x8 GTMs (8.28.0.9 and 192.84.18.11) as the Primary and Secondary DNS servers in the VLANs DHCP Scope. An alternate option is to implement conditional forwarding of 8x8.com and packet8.net on your local DNS servers to 8.28.0.9 and 192.84.18.11, which are 8x8's DNS servers. It is not recommended to set conditional forwarding on your Data VLAN and/or if you have only 1 network. If your network only consists of a single line (you are not using VLANs), 8x8 can set the DNS of your hard phones to the GTMs.

Some of the required UC UDP ports (5061,5196,5197,5198,5299,5301,5399,5401,5443) are being blocked by your firewall or ISP gear, and there are 2 options to resolve this issue:

-- OR –

  • Our recommendation is to create an "Any to 8x8" rule in your firewall. The is a highly secure action as it is only opening outbound traffic towards a known destination (our 8x8 data center(s)). The list of our subnets is listed in the technical document previously supplied, or you may even simply use packet8.net and 8x8.com domains.

DHCP Option 160 is enabled. Disable this option in your DHCP Scope.

DHCP Option 42 is enabled. Review this value to ensure it is a valid functional NTP Server.

MOS score is below recommended value of 3.0.

Update to the most current version of NetUtil here.

Some of the required SIP ports are being blocked by your firewall. Explicitly open these ports in your firewall as per the technical requirement document.

There is a closer data center based on the minimum average latency, but the difference is less then 50 ms, this is considered irrelevant.

Geo Routing placed you outside your region.

DNS returned an IP that is not in 8x8 ranges.