This article is for administrators.To learn how to set up and manage your own meetings, go to the Meet help center.
To provide high-quality meetings with Google Meet, you need to set up your network so that Meet can efficiently communicate with the Google infrastructure.
- Make sure Meet traffic has a short path to the internet.
- Avoid proxies, packet inspection, protocol analyzers, and quality of service (QoS).
- Measure and optimize latency, bandwidth, and your Wi-Fi network
Set up your networkStep 1: Allow access to Google IP address ranges
- For media (audio and video), set up outbound UDP ports 3478 and 19302–19309. If you want to limit the number of Chrome WebRTC ports being used, see Chrome WebRTC UDP Ports setting. Alternatively you can limit those ports via your firewall.
- For web traffic and user authentication, use outbound UDP and TCP port 443.
- These ports are allowed without any IP limitation.
- TCP will be used if these UDP ports are blocked.
- Sustained use of TCP or proxied TCP by any participant can degrade overall meeting quality.
The core Google services need full network access. If there are restrictions or filtering policies for users on your network, give network access to the HTTPS endpoints.
Domains for static resources
Domains for API endpoint connectivity
Domains for live streaming
* Meet feedback functionality is loaded from URLs starting with https://www.google.com/tools/feedback and https://feedback.googleusercontent.com/resources/
Allow access to the following IP address ranges to enable audio and video media traffic. If your organization must support Meet traffic over port 443, add Meet SNI to your firewall or proxy allowlist to enable audio and video traffic over TLS.
Note: These IP addresses are different from the URIs specified in step 2.
Google Workspace IP address ranges
These IP ranges are used exclusively for Meet to identify meeting traffic used with your organization’s Google Workspace accounts and to deprioritize Meet traffic from consumer accounts.
Allow access to Meet's media servers using the following set of IP ranges and SNI:
- IPv4: 184.108.40.206/24
- IPv6: 2001:4860:4864:5::0/64
- SNI: workspace.turns.goog
Consumer IP address ranges
The following IP ranges are used exclusively for media traffic coming from participants who are signed in to a personal Google Account or not signed in to any account.
Allow access to Meet's media servers using the following set of IP ranges:
- IPv4: 220.127.116.11/24
- IPv6: 2001:4860:4864:6::/64
- SNI: meet.turns.goog
Calculate minimum Meet bandwidth requirements
Bandwidth requirements per participant
The bandwidth used by Meet varies to provide the best experience on participants’ networks.
|Average bandwidth per participant|
|HD Video||2.2 Mbps||1.6 Mbps|
|Audio only||12 Kbps||18 Kbps|
|Ideal bandwidth per participant|
|2-person HD video meetings||1.7 Mbps||1.7 Mbps|
|Group video meetings||0.7 Mbps||2.0 Mbps|
Estimate peak number of concurrent participants
Determine the number of concurrent participants based on how important meetings are at each site, as shown in the following table.
|Importance of meetings||Peak number of concurrent meetings|
For example, if meetings are of high importance, estimate that 20% of the users at that site will use Meet. If video meetings are of low importance, only 0.5% of people at that site might be in a meeting at the same time.
Bandwidth requirements per live stream viewer
If your organization live streams video meetings, the ideal bandwidth for each viewing participant is 2.6 Mbps. The default high-quality video setting is 720p and is used if the participant has enough individual bandwidth.
If sufficient bandwidth isn't available, viewers can also optionally choose to reduce the Meet video quality.
|Meet video setting||Inbound bandwidth required||Notes|
|720p||2.6 Mbps||Default high quality setting results in the best user experience|
|240p||0.5 Mbps||Results in a poor viewer experience and is not recommended|
Network best practices
We strongly recommend that you do not use proxy servers for Meet traffic.
Proxying traffic adds latency and can cause Meet to automatically reduce the video and audio quality. Meet performance is best when the latency between the client and Google back end is lower than 100 ms. Also, Meet provides the same benefits for video traffic that a proxy does, so a proxy isn’t needed.
If proxy servers must be used in your network
If you have a clear use case that absolutely requires the use of a proxy, understand that proxy servers can severely impact performance and make sure:
- To allow access to Meet traffic in the proxy configuration.
- Meet uses the Chrome Proxy settings.
- The network bypasses the proxy for Meet IP address and SNI.
The Socket Secure (SOCKS5) internet protocol is not currently supported.
We recommend that you do not run Meet using virtual desktop infrastructure (VDI) environments, such as Citrix and VMware.
VDI environments create an extra layer of latency and complexity, which can slow Meet and result in a lower-quality Meet experience. While using VDI is not recommended, you can take steps to reduce the impact of VDI usage on Meet:
- Ensure Google Meet can detect that it’s running inside a virtual machine (VM) by enabling the Enterprise Hardware Platform API policy in Chrome. For details, go to Set Chrome policies for users or browsers and the API page.
- Allocate at least 4 virtual CPUs for each VM instance.
- Use GPU-enabled VM instances to accelerate video encoding and background effects, such as blur.
- Ensure sufficient bandwidth and low latency between clients, virtual desktops, and Meet media servers. For bandwidth requirements between Meet media servers and VMs, see Step 4 (above on this page). Find the required bandwidth for the connection between VDI clients and VMs by consulting your VDI provider.
The following recommendations apply to typical office environments. A wireless engineer should evaluate more complex environments, such as manufacturing floors, areas with high levels of radio frequency (RF) noise, or sparsely covered spaces.
Carefully review the following considerations during the design, deployment, and operation of wireless networks used by Meet.
2.4 GHz versus 5 GHz RF bands
We recommended that your network force clients onto the 5 GHz RF band, if available.
We recommend you not deploy and operate Meet over the 2.4-GHz band of a wireless network as it’s typically heavily used. The 2.4-GHz band is also less reliable because it has 3 non-overlapping channels, typically high noise levels from nearby interfering networks, and extra interference from other devices.
Design and deployment considerations
For the wireless network, think about capacity rather than coverage.
- Manage cell size—Control cell size 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. Use bigger cells to provide general coverage on the office floor.
- Disable low rates to improve RF usage efficiency and force 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 force clients onto the 5-GHz 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 standalone APs.
Finally, perform a post-deployment wireless survey to confirm wireless coverage in the spaces where Meet is typically used.
To support reliable Meet communication over wireless networks, you should implement Wireless Multimedia Extensions (WMM).
Meet traffic needs to be classified by one of the following ways:
- The wireless controller or AP based on the Meet-specific protocols and ports.
- The Differentiated Services Code Point (DSCP) field value set by other network equipment. Use DSCP if you have sufficient trust in the network.
While full WMM support (including clients) is required to provide bidirectional QoS, you can configure it at the network level (on the controller or AP) to give significant benefits. Meet traffic should be assigned to the audio or video queue on the wireless AP or controller and be preferred over other classes of traffic.
If you must use QoS
In the Admin console, go to Menu AppsGoogle WorkspaceGoogle Meet.
- Click Meet video settings.
- On the left, select the organizational unit you want to manage. For all users, select the top-level organizational unit.
- 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 click to turn on their camera in the Meet browser window, but uplink video will be limited to 1 Mbps by default.
- Apply the settings:
- If the setting is for the top-level organizational unit, click Save.
- If the setting is for a child organizational unit and is different than the parent, click Override.
Google, Google Workspace, and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.