Here are some best practices to set up your network for Google Voice calls.
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:
- Latency: max 150 ms one way delay (ITU G114)
- Bandwidth: 50 kbps recommended
- Wi-Fi network: See WiFi best practices
We strongly recommend your network does not use proxy servers for Voice traffic:
- In the proxy configuration, put Voice traffic on an allowlist.
- Voice does not do fallback to TCP as Google Meet does. Voice uses UDP only for voice traffic.
- Proxying traffic adds latency and might cause Voice to automatically reduce the audio quality. Voice performance is optimal when the latency between the client and Google backend is lower than 100 ms.
- Socket Secure (SOCKS5) internet protocol is not supported.
If possible, do not use packet inspection or protocol analyzers for Voice. They introduce latency that might 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, put all Voice traffic port numbers on an allowlist to bypass the tools.
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 versus 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 recommendation includes applications 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, which 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 might create an unpredictable user experience.
- Wireless-connected desk phones should not be used by high density/high voice call teams, such as agents or support teams. For example, GOVO sites or 24/7 call centers.
- Short voice interruptions, 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, such as 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.
Voice traffic is secured and encrypted, so there’s no need to restrict traffic to the Google IPs.
If, however, you have network constraints that require you to restrict traffic, put the following set of IP ranges on an allowlist to allow Voice media servers. The IPs are used exclusively for Voice for Google Workspace so you can identify voice traffic used in Google Workspace 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
Set up your network so the following ports allow voice traffic to flow to and from your organization:
- Outbound UDP ports 19302 to 19309
- Outbound TCP port 443
Note: Voice port range 19302 to 19309 uses the Chrome WebRTC UDP Ports Setting. To learn more, read Set Chrome policies for users or browsers.
