Troubleshooting

Problem: You cannot find your 8x8 Network Utility test logs.

Possible solution: All logs generated by the 8x8 Network Utility are located in a specific location based on your operating system:

• On Windows: %AppData%\Roaming\8x8 Diagnostics
• On Mac: ~/Library/Application Support/8x8/

In the appropriate location, you find a copy of each test run by this installation of the 8x8 Network Utility; each entry is stamped with the date and time. If there is an issue, please make sure to zip all files in this folder, and send to your 8x8 network engineer for review.

Problem: You have installed the 8x8 Network Utility manually, and the application fails to open.

Possible solution: Make sure you have .NET 4.5 installed on your system.

Your media test may have returned errors because your network was not in the maximum acceptable limits for the test:

• Your packet loss is more than 0.3%.

  Packet loss is caused within routers. When a router is overloaded, the router drops packets, which severely limits sound quality and performance. The performance of a call suffers if packet loss exceeds 0.3%.

  Problem: Packet delay can cause severe issues in latency-sensitive applications that use VoIP. Delays can occur in the data network depending on router configuration, network capacity, and performance load on the equipment.

  Possible solution: If you encounter packet loss higher than our recommended levels, we recommend that you check the local network to make sure there are no congested links or bottlenecks in the local network. If you find congested links or bottlenecks, try to remove them, or increase the bandwidth at that point. We highly recommend that you implement Quality of Service to give priority to your voice packets.

  In rare cases, older firmware or uncommon equipment may cause packet loss due to the nature of older firmware or limitations in performance. We also recommend that you run a third-party utility called PingPlotter in order to pinpoint where packet loss is introduced along the route from your location to our data center.

• Your jitter rate is more than 20.

  Jitter is variation in packet transit delay caused by queuing, contention, and serialization effects along the path through the network. In general, higher levels of jitter are more likely to occur on either slow or heavily-congested links.

  Problem: Packets sent from one end of a call can appear to be sent in a continuous stream, but since each packet may take a different route to its destination, network congestion or improper configuration can result in jitter. If the packets are not received in the same order as they were sent, or were dropped entirely on the way, jitter occurs. Jitter that exceeds 40 ms causes severe voice quality issues. A high level of jitter is usually a consequence of slow speeds or congested networks.

  Jitter may be measured in a number of different ways, several of which are detailed in various Internet Engineering Task Force standards for RTP (such as RFC 3550 and RFC 3611). Some methods suggested are as follows:

  • Mean packet to packet delay variation
  • Mean absolute packet delay variation
  • Packet delay variation histograms
  • Y.1541 IPDV Parameter

  Possible solution: The first thing to check is to verify the Quality of Service (QoS) settings of the company network. QoS control mechanisms include class-based queuing, bandwidth reservation, and usage of higher speed links. If QoS has not been configured fully or properly, voice packets do not receive the proper priority, which results in missed or discarded packets. Audio calls then experience 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 buffer size can be increased up to a point. Generally, jitter buffers are only effective for delay variations of less than 100 ms, but users may still notice a drop in quality. There are various tools available that can be used by experts to identify and remove sources of jitter instead of relying on jitter buffers.

• Your latency is more than 120 ms.

  Latency is the time it takes to move voice packets from the phone to 8x8 and back.

  Problem: If voice packets take too long to travel, audio can degrade or disappear. To prevent poor voice quality, latency should not exceed 150 ms in one direction.

  Note: When part of the call travels over the public Internet (which introduces its own latency), your organization's internal network latency should be significantly less than 100 ms in order to prevent poor voice quality.

  Possible solution: In most cases, latency is introduced by a congested network, or a carrier issue. We also recommend that you run a third-party utility called PingPlotter to get a better overall view of your network, in addition to running a bufferbloat test using the 8x8 Network Utility.

  If you encounter latency higher than our recommended levels, we recommend that you check the local network to make sure there is no network congestion, and no carrier issues. We recommend that you open a ticket with your carrier to have their network reviewed if you suffer from continued latency issues. Prioritizing VoIP traffic over the local network (and, if possible, the WAN) can also help prevent latency and jitter issues. We also recommend that you run a third-party utility called PingPlotter in order to pinpoint where packet loss is introduced along the route from your location to our data center.

Fragmentation is a technique that divides a data packet into smaller data packets so they can be sent through a network that only transfers small data packets. Fragmentation occurs during network transmission. When fragmented packets are received at their destination, they are reassembled to their original packet size.

Problem: In rare cases, signaling packets may become extremely large and must be fragmented. If fragmentation is not supported, callers may experience audio loss.

Possible solution: We recommend that fragmentation be supported by all network equipment, including routers, and that your MTU be set to 1500B on all networking gear.

Depending on the milliseconds of round-trip delay when your connection is fully utilized (taken as the average of down bloat and up bloat), the bufferbloat test applies grades as follows.

• Less than 5 ms: A+
• Less than 30 ms: A
• Less than 60 ms: B
• Less than 200 ms: C
• Less than 400 ms: D
• 400 ms or more: F

To get an A+ grade, you must calculate ((average of uplift during upload)+(average of uplift during download))/2 and get a result of less than 5 ms. Note that there is no "E" grade.

Problem: Your bufferbloat test is showing that your network has a long round-trip delay.

Possible solution: For details on bufferbloat and how to decrease it, please refer to bufferbloat.net.

The DNS test may return one or more of the following errors depending on the setup of your network:

• Mismatch in DNS resolutions

  Problem: The test detected that geo-routing as determined by your DNS server would be using a suboptimal route, which could impact your audio quality.

  Possible solution: The resolution mismatch may be due to incorrect forwarding of the 8x8 domain queries. We recommend that you 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 the DNS servers of 8x8. For details, please refer to the Microsoft page on conditional forwarders for domain names.

  Alternatively, you can implement a voice-only VLAN and set the DNS servers to <8.28.0.9> and <192.84.18.11>, which are the DNS servers of 8x8.

  Note: The suggested DNS servers only resolve 8x8.com and packet8.net domains. Due to this restriction, you must also set Option 42 to point to a local NTP server.

• ALG Enabled

  Problem: The test detected that ALG is currently enabled on your edge firewall.

  Possible solution: We recommend that ALG be disabled on all your network gear, as it is known to cause performance issues in 8x8 services. For details, please refer to our page on disabling SIP-ALG in your router or firewall.

• Outbound Connectivity test

  Problem: The test detected that there are multiple ports that are blocked. 8x8 uses wide ranges of both TCP and UDP ports. As a cloud-based solution, it is essential that 8x8 be able to communicate with our secure subnet.

  Possible solution: A secure way 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 (for outbound ports only). These subnets are listed in the technical requirements for 8x8 X Series. Opening the required ports ensures that all traffic from all your internal LAN IP ports should be able to communicate with all IP ports on the 8x8 subnet.

  Alternatively, you can explicitly open these ports in your firewall, as listed in the above technical requirements document.

• NAT Failed

  Problem: The test detected that all NAT tests failed.

  Possible solution: Please review your network edge device to ensure that all ports are open, and that a valid gateway is provided. Note that there is no double NAT/Load balancing on ISPs.

• Windows Time Failed

  Problem: The test detected that your phones are not able to sync with one or both of the following time servers:

  • ntp.pool.org
  • Your machine’s default NTP

  Possible solution: We recommend that you enable access to these time servers, or reference the time servers of 8x8 at ntp.packet8.net. These servers are used to establish the proper time on your phone, and are used in the registration process for security purposes.

• Ping Failed/Excessive Latency

  Problem: The test detected that the Ping/Time portion of the media test took a higher than acceptable amount of time to run.

  Possible solution: Please make sure that ICMP is enabled on your firewall; this is not necessary for any 8x8 services, but is important to help detect latency issues. Make sure that you are not checking the values to the wrong data center.

Problem: DHCP Option 66 is enabled.

Possible solution: Please disable Option 66 in your DHCP Scope. 8x8 phones come pre-configured with a provisioning URL; if Option 66 is enabled, the URL is overwritten. For details, please refer to our page on provisioning phones that are not provided by 8x8.