Prepare your network for Meet meetings

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.

You should:

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

Expand all | Collapse all

Set up your network

Step 1: Set up outbound ports for media traffic

Update your firewalls to allow media traffic to flow to and from your organization:

For 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, use the ports specified at WebRTC UDP Ports.
- Alternatively, you can limit those ports with your firewall.
For web traffic and user authentication, use outbound UDP and TCP port 443.

The ports are allowed without any IP limitation. If UDP ports are blocked, TCP will be used. However, sustained use of TCP or proxied TCP can degrade overall meeting quality.

Step 2: Allow access to uniform resource identifiers (URIs)

Meet needs full network access.

If there are restrictions or filtering policies for users on your network, give network access to the uniform resource identifier (URI) patterns below on this page using port 443.
If you're using a Google Meet hardware product, review the networking requirements for ChromeOS at Set up TLS (or SSL) inspection on Chrome devices.

Domains for static resources

clients2.google.com
clients4.google.com
clients6.google.com
www.gstatic.com
fonts.gstatic.com
lh3.googleusercontent.com
meetings.clients6.google.com

Domains for API endpoint connectivity

accounts.google.com
apis.google.com
meetings.googleapis.com
hangouts.googleapis.com
meet.google.com
apps.google.com
jamboard.google.com
docs.google.com

Domains for live streaming

stream.meet.google.com
youtube.googleapis.com
www.youtube-nocookie.com
googlevideo.com

Domains for user feedback and event log uploads

https://www.google.com/tools/feedback
https://feedback.googleusercontent.com/resources/
https://play.google.com/log

Step 3: Allow access to Google IP address ranges (for audio and video)

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. These IP addresses are different from the URIs specified in step 2.
Add Google Workspace IP address ranges (for your users). Allow access to Meet's media servers using the following set of IP ranges and SNI:
- IPv4: 74.125.250.0/24
- IPv6: 2001:4860:4864:5::0/64
- SNI: workspace.turns.goog
For interactive live streaming: Add consumer IP address ranges. Allow access to Meet's media servers using the following set of IP ranges:
- IPv4: 142.250.82.0/24
- IPv6: 2001:4860:4864:6::/64
- SNI: meet.turns.goog

Step 4: Review bandwidth requirements

Your network should have enough bandwidth for concurrent HD video meetings, plus additional bandwidth for other needs, such as live streaming. Number of participants, screensharing, and other factors also affect bandwidth usage.

If your network doesn't have enough bandwidth, Meet lowers the video definition to fit your network's constraints. If your network doesn't have enough bandwidth to support video, Meet will use audio instead.

Calculate minimum Meet bandwidth requirements

To calculate the minimum bandwidth requirement for your organization, multiply the average bandwidth per participant by the peak number of concurrent participants. Many factors, such as number of participants, layouts, and screensharing, can affect bandwidth usage. Still screen shares don't take up any more bandwidth after they load.

Average bandwidth per participant for large organizations
Meeting type	Outbound	Inbound
Video	1 Mbps	1.3 Mbps
Audio only	12 Kbps	18 Kbps

Bandwidth per participant for small organizations or individuals
Meeting type	Outbound	Inbound
1080p video	Up to 3.6 Mbps	Up to 3.6 Mbps
720p video	Up to 1.7 Mbps	Up to 1.7 Mbps
Group meeting	250 Kbps and up*	Up to 4.0 Mbps
Audio only	100 Kbps	100 Kbps

*Depending on the resolution sent

Estimate peak number of concurrent participants

If Meet meetings are a high priority for users, estimate that 20% of the users in your organization will use Meet at any one time. If Meet meetings are a low priority for users, only 0.5% of people might be in a Meet meeting at the same time.

Priority of video meetings	Estimated amount of concurrent meeting participants
High	10–20%
Normal	1–4%
Low	0.01–0.5%

Bandwidth requirements per live stream feed

If your organization live streams meetings, the ideal bandwidth for each viewing feed is 2.6 Mbps. The live stream has dynamic layout and sizing options. It also optimizes for user device capabilities like window size and aspect ratio. Meet uses the default high-quality video setting if the participant has enough individual bandwidth.

If viewers don't have enough bandwidth, they can choose to reduce Meet quality.

Single Video Feed (bitrate kilobit/s)

Resolution	Minimum	Maximum
180p	80	200
360p	200	500
540p	400	1000
720p	600	1500

Screen Share Feed (bitrate kilobit/s)

Resolution	Minimum	Maximum
Minimum Quality	200	200
360p	250	500
720p	750	1500
1800p	1300	2600

Network best practices

Using Wi-Fi

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.

Using WMM

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.

Using VDI

VDI environments create an extra layer of latency and complexity, which can slow Meet and result in a lower-quality Meet experience. Background effects are limited, and greenroom preview is not available.

While using VDI is not optimal, 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.
A GPU is not required for cloud-effects based video processing for background effects, but GPU-enabled VM instances increase reliability of 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.

Avoid using Proxies

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.

Avoid using QoS

You shouldn’t use quality of service (QoS) for Meet in your network because Meet automatically adapts to network conditions. Use QoS only if you have a compelling reason, such as a congested network, and are able to deploy and maintain an end-to-end QoS model in your network.

If you must use QoS

Employ the best practices described in the Meet QoS best practices guide.

Avoid using VPNs

We strongly recommend that you do not use a VPN for Meet traffic. VPNs add latency and can cause Meet to automatically reduce video and audio quality.

If you must use a VPN:

Enable split tunneling for your VPN
Route the domains from Step 2 outside the VPN using the DNS or SNI (SNI is recommended)
Route the IP ranges from Step 3 outside the VPN via prefix matching

Configuring default video quality

To reduce bandwidth usage, set the default for Meet video quality in the Google Admin console.

This setting only applies to web browsers and it doesn’t affect Google 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 to each new meeting the user joins.

Sign in to your Google Admin console.
Sign in using your administrator account (does not end in @gmail.com).
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:
1. If the setting is for the top-level organizational unit, click Save.
2. If the setting is for a child organizational unit and is different than the parent, click Override.