This article is for administrators. To learn how to set up and manage your own meetings, go to the Meet help center.
This article is for IT admins who manage Meet for large orgs with hundreds or thousands of people and complex network needs. If that's not you, you probably don't need to read this very technical article.
If you're an IT admin who wants to troubleshoot your network for Meet, go to Troubleshoot Meet network, audio, and video issues as an admin.
If you're trying to turn off Meet for your whole organization, check out Turn off Meet meetings and calls for your organization.
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.
Set up your network
Step 1: Set up outbound ports for media traffic- 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.
- Or, 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 limit. If UDP ports are blocked, TCP will be used. Use of TCP or proxied TCP can decrease overall meeting quality.
Meet needs full network access.
- If there are restrictions or filtering policies for users on your network, give network access to the URI patterns below on this page using port 443.
- If you're using Google Meet hardware, 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 & event log uploads
- https://www.google.com/tools/feedback
- https://feedback.googleusercontent.com/resources/
- https://play.google.com/log
- 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
- If your organization uses low-latency live streaming, live streaming media traffic will prefer using the UDP protocol. This traffic will use the Workspace IP ranges (similar to Meet) instead of YouTube HTTP IPs.
- 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
Your network should have enough bandwidth for multiple HD video meetings. It should also have extra bandwidth for other needs, like live streaming. Number of participants, screen sharing, and other factors also affect bandwidth usage.
If your network doesn't have enough bandwidth, Meet lowers the video definition. If your network doesn't have enough bandwidth to support video, set Meet to Audio only.
To stream using less bandwidth, Host large live streams with less bandwidth using eCDN.
Calculate minimum Meet bandwidth requirements
To calculate the minimum bandwidth needed for your organization, multiply the average bandwidth per participant by the peak number of concurrent participants.
Many factors, like number of participants, layouts, and screen sharing, can affect bandwidth usage. If a screen share is still, it doesn't take up any more bandwidth after it loads.
| 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, estimate that 20% of the users in your organization will use Meet at any one time. If Meet meetings are a low priority, only 0.5% of people might be in a Meet meeting at any one 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
If your organization live streams meetings, the ideal bandwidth for each viewer is 2.6 Mbps.
Live stream tiles have a dynamic layout based on the size and orientation of the viewer's window.
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 or use audio only.
Single video tile (bitrate kilobit/s)
|
Resolution |
Minimum |
Maximum |
|
180p |
80 |
200 |
|
360p |
200 |
500 |
|
540p |
400 |
1000 |
|
720p |
600 |
1500 |
Screen share tile (bitrate kilobit/s)
|
Resolution |
Minimum |
Maximum |
|
Minimum Quality |
200 |
200 |
|
360p |
250 |
500 |
|
720p |
750 |
1500 |
|
1800p |
1300 |
2600 |
The quality of live streamed media is affected by the original quality of the media and how media is sent into Meet. You can check and compare quality by joining the main Meet call for the live stream as a regular participant.
Bandwidth for classic live streaming (not ultra-low latency)
Check which version of live streaming your domain is using by looking at the client. The classic live streaming client has a white bar across the top with controls in it. The new live streaming client uses a dark theme like Meet and all controls are located at the bottom.
Classic live streaming as a single video feed with fixed aspect ratio and bandwidths are stated for the entire composite feed.
| Resolution | Minimum | Maximum |
|---|---|---|
| 360p | 400 kbps | 1 Mbps |
| 720p | 1.5 Mbps | 4 Mbps |
| 1080p | 3 Mbps | 6 Mbps |
The actual bandwidth changes based on the type of content on the live stream.
Network best practices
To reduce bandwidth usage, set the default for Meet video quality in the Google Admin console.
This setting only applies to web browsers. 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
Apps
Google Workspace
- 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 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.
- Audio only—Video is turned off by default. Users can click
to turn on their camera in the Meet browser window. Uplink video will be limited to 1 Mbps.
- 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.
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 noise
- 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 often heavily used. The 2.4-GHz band is also less reliable because it has 3 non-overlapping channels, high noise levels, and extra interference.
Design & deployment considerations
For your 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 an office floor.
- Disable low rates to improve RF usage efficiency—Force a client’s handover to the closest AP while roaming between APs.
- Manage your network centrally—To allow advanced features, like seamless roaming between APs and proper RF management, a wireless network should be centrally managed and operated. It should not be a collection of standalone APs.
- Perform a post-deployment wireless survey—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 in 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.
Full WMM support is required to provide bidirectional Quality of Service. However, you can configure it at the network level for significant benefits. Meet traffic should be assigned to the audio or video queue on the wireless AP or controller. Meet traffic should be preferred over other classes of traffic.
VDI environments create an extra layer between Meet and the internet. This can slow Meet and result in a lower-quality experience. Background effects are limited, and greenroom preview is not available.
To reduce the impact of VDI usage on Meet, you can take the following steps:
- 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 background effects, but GPU-enabled VM instances increase reliability.
- 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.
Best practice is not to use proxy servers for Meet traffic. Proxying traffic adds latency which can cause reduced video quality.
If proxy servers must be used in your network
If you need to use 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.
- You have a compelling reason, such as a congested network
- are able to deploy and maintain an end-to-end QoS model in your network.
If you must use QoS
Best practice is not to use a VPN for Meet traffic. VPNs add latency and can cause Meet to 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
Related topics
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.
