Optimize your network for Voice

Here are some best practices to set up your network for Voice calls:

Create a cloud-friendly network

A cloud-friendly network infrastructure allows Voice traffic to efficiently communicate with the Google infrastructure. To create this:

  • Make sure Voice traffic has a short path to the internet. Avoid:
    • Proxies
    • Packet inspection or protocol analyzers
  • Measure and optimize:

Proxy best practices

We strongly recommend your network does not use proxy servers for Voice traffic:

  • Whitelist Voice traffic in the proxy configuration.
  • Voice does not do fallback to TCP as Meet does. Voice uses UDP only for voice traffic.
  • Proxying traffic adds latency and may cause Voice to automatically reduce the audio quality. Voice performance is optimal when the latency between the client and Google back end is lower than 100 ms.
  • Socket Secure (SOCKS5) internet protocol is not supported.

Packet inspection/protocol analyzers

If possible, do not use packet inspection or protocol analyzers for Voice. They introduce latency that may cause the Voice infrastructure to automatically reduce audio quality.

Packet inspection of audio traffic also yields little benefit because automated scanning tools can’t reconstruct audio stream data.

If these tools are used, whitelist all Voice traffic port numbers to bypass them.

Wi-Fi best practices

The following recommendations apply to typical office environments. A wireless engineer should evaluate on a case-by-case basis more complex environments, such as manufacturing floors, areas with high levels of radio frequency (RF) noise, or sparsely covered spaces.

Running real-time applications over a wireless network can be challenging because the underlying RF spectrum and bandwidth is shared among all the devices using it.

Carefully review the following considerations during the design, deployment, and operation of wireless networks used with Voice.

2.4 GHz vs 5 GHz RF bands

We generally recommend that real-time applications not be deployed and operated over the (typically heavily used) 2.4 GHz band of a wireless network. This includes those that provide connectivity in an ordinary office environment.

The 2.4 Ghz band is problematic because it has only 3 non-overlapping channels, typically high noise levels from nearby interfering networks, and extra interference from other devices (microwaves, for example), creating a noisy and complex RF environment.

Reliable operation of real-time applications like Voice relies on adequate capacity, delay, jitter, and packet-loss levels. These are almost impossible to achieve over the 2.4 GHz band.

Design/deployment considerations

If you design a wireless network to support real-time applications, think about capacity rather than coverage.

  • Manage cell size, which is controlled by the transmit power of the access point (AP). Deploy smaller cells where more devices are expected, such as meeting rooms and auditoriums to increase capacity. Bigger cells can provide general coverage on the office floor.
  • Disable low rates to improve RF usage efficiency. This forces a client’s handover to the closest AP while roaming between APs.

If a wireless network’s SSID is available on both bands (2.4 GHz and 5 GHz), the network should implement aggressive band steering to force clients onto the 5 GHz band.

  • A realistic expectation is no more than 10 desk phones connected on the same AP. A larger number may create an unpredictable user experience.
  • Wireless-connected desk phones should not be used by high density/high voice calls teams, such as agents or support teams. For example, GOVO sites or 24x7 call centers.
  • Short voice blackouts, less than 10 seconds, are to be expected and cannot be eliminated at the network level for wireless connected desk phones. We do not recommend wireless networks for placing high-profile phone calls. For example, conferences, press meetings, or executive calls.
  • Although regulations vary by countries/regions, a common requirement is Wi-Fi devices that are using DFS channels to make sure it will not interfere with your local weather radar system, for example. As a result, an AP subject to radar interference will vacate the channel. All clients will have to reconnect to a different AP operating on a different channel.

To allow advanced features, such as seamless roaming between APs and proper RF management, a wireless network should be centrally managed and operated—not a collection of siloed, standalone APs.

Finally, perform a post-deployment wireless survey to confirm wireless coverage throughout the spaces where Voice is typically used.

Whitelist Voice IP address range

Voice traffic is secured and encrypted, so there’s no need to restrict traffic to the G Suite IPs.

If, however, you have network constraints that require you to restrict traffic, use the following set of IP ranges to whitelist Voice media servers. The IPs are used exclusively for Google Voice for G Suite, which allows you to identify voice traffic used in G Suite and deprioritize Voice traffic from consumer accounts. This can help you better set up and optimize network and firewall access.

  • IPv4: 74.125.39.0/24
  • IPv6: 2001:4860:4864:2::0/64
Was this helpful?
How can we improve it?