2. Optimize your network for Meet
The network requirements and other information in this article applies to both Hangouts Meet and classic Hangouts.
To set up your network for the best possible Meet video meetings:
- Make sure the site has enough bandwidth for the maximum number of participants meeting concurrently. See Network connectivity requirements for Meet.
- Configure the network for low latency between the participant devices and Google. To achieve this:
- Create a Cloud-friendly network.
- Do not use proxies, QoS, or packet inspection or protocol analyzers.
These features can impact Meet video and audio quality. They introduce or alter latency and jitter, which is used to estimate network congestion and available bandwidth.
If proxies, QoS, or packet inspection/protocol analyzers must be used, see the following information to properly implement these features.How Meet adapts to network constraints
Meet automatically adapts to the available bandwidth by detecting network congestion using the GCC (Google Congestion Control) algorithm.
If media packets stop arriving as frequently as they were before, then the packets were buffered in a network node that does not have enough capacity to send them forward. Meet uses this information to determine that the network is congested and adapt the media stream bitrates.
A Cloud-friendly network infrastructure allows Meet traffic to efficiently communicate with the Google infrastructure. To create this:
Do not use proxy servers for Meet traffic
We strongly recommend that your network not use proxy servers for Meet traffic. To do this, whitelist Meet traffic in the proxy configuration.
Proxying traffic adds latency and may cause Meet to automatically reduce the video and audio quality. Meet performance is optimal when the latency between the client and Google back end is lower than 100 ms. In addition, Meet provides all the benefits for video traffic that a proxy does, so a proxy is not needed.
If proxy servers must be used
We strongly advise against the use of a proxy. But if you have a clear use case that absolutely requires it, understand that proxy servers can severely impact performance. If proxies are used in your network, note the following:
If at all possible, do not use packet inspection or protocol analyzers for Meet, because they introduce latency that may cause the Meet infrastructure to automatically reduce video meeting quality. The additional latency often severely impacts real time traffic such as video conference. This additional latency is often high enough to prevent video meetings from functioning.
Packet inspection of video traffic also yields little benefit, because automated scanning tools can’t reconstruct media stream data.
If these tools are used, whitelist all Meet traffic port numbers to bypass them.
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 RF noise, or sparsely covered spaces.
Running real-time applications over a wireless network can be challenging. This is because the underlying radio frequency (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 Meet.
2.4GHz vs 5GHz RF bands
We generally recommend that real-time applications not be deployed and operated over the (typically heavily used) 2.4GHz band of a wireless network. This includes those that provide connectivity in an ordinary office environment.
The 2.4Ghz 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 radiofrequency (RF) environment.
Reliable operation of real-time applications like Meet rely on adequate capacity, delay, jitter and packet-loss levels. These are almost impossible to achieve over the 2.4 GHz band.
If you design a wireless network that will 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.4GHz and 5GHz), the network should implement aggressive band steering to force clients onto the 5GHz band.
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 Meet is typically used.
WMM best practices
To support reliable Meet communication over wireless networks, implement Wireless Multimedia Extensions (WMM).
Meet traffic needs to be classified by the wireless controller/AP based either on the Meet-specific protocols and ports or, if sufficient trust is present in the network, by the DSCP field value set by other network equipment.
While full WMM support (including clients) is required to provide bidirectional QoS, you can also configure it at the network level (on the controller/AP) to provide significant benefits. Meet traffic should be assigned to either the audio or video queue on the wireless AP/controller and receive preferential treatment over other classes of traffic.
Meet traffic is secured and encrypted, so there is 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 Meet’s media servers. The IPs are used exclusively for Google Meet, which allows you to identify video conference traffic used in G Suite and deprioritize Hangouts traffic from consumer accounts. This can help you better configure and optimize network and firewall access.
- IPv4: 22.214.171.124/24
- IPv6: 2001:4860:4864:5::0/64
Do not use QoS
You should not use QoS for Meet in your network, because Meet automatically adapts to network conditions. Use QoS only if you have compelling reasons, such as a congested network, and are able to deploy and maintain an end-to-end QoS model in your network.
If QoS must be used
If your network is congested and you must secure a certain quality of service (QoS) for Meet, employ the best practices described in the following document.
- Limit at the network level: To control Meet bandwidth usage at network level, use QoS to reserve or limit traffic for Meet. See QoS best practices above for more information.
- Limit at the client level: To limit Meet bandwidth usage for users in a specific organizational unit, set the default video quality from your Admin console in Meet’s settings.
From the Admin console Home page, go to AppsG SuiteGoogle Hangouts.
- Click Meet settings.
Select the desired organizational unit.
(Otherwise, your settings apply to your entire organization.)
Select a Default video quality option:
- Adjust automatically (default)—The bandwidth is adjusted for network and system conditions to provide the best possible quality.
- Limited video bandwidth—Uplink bandwidth is limited to 1 Mpbs by default to limit bandwidth usage.
- Audio only—Video is turned off by default. Users can manually turn on their camera, but uplink video will be limited to 1 Mbps by default.
Note: This setting only applies to web browsers and it does not affect Hangouts Meet hardware or the Meet mobile apps. Users can overrule the organizational unit default value in their browser by enabling video in the Meet meeting and changing the video quality. The default setting will apply for each new meeting the user joins.