Prepare your network for Meet meetings & live streams

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.

Expand all  |  Collapse all

Set up your network

Step 1: Set up outbound ports for media traffic
Update your firewalls to let media traffic 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
    • 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.

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

Meet needs full network access.

  1. 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.
  2. 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

  • meet.google.com
  • stream.meet.google.com

Domains for user feedback & 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)
  1. 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.
  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
  3. 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.
  4. 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 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 viewing feed is 2.6 Mbps. Live streams have dynamic layout and sizing options. Device capabilities like window size and aspect ratio are optimized. 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.

Network best practices

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. 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.

  1. Sign in to your Google Admin console.

    Sign in using your administrator account (does not end in @gmail.com).

  2. In the Admin console, go to Menu and then Appsand thenGoogle Workspaceand thenGoogle Meet.
  3. Click Meet video settings.
  4. On the left, select the organizational unit you want to manage. For all users, select the top-level organizational unit.
  5. 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.
  6. 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.
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 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.

Using VDI

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.
Avoid using Proxies

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:

The Socket Secure (SOCKS5) internet protocol is not currently supported.

Avoid using QoS
Best practice is not to use quality of service (QoS) for Meet in your network. Only use QoS if:
  • 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

Use the best practices described in the Meet QoS best practices guide.
Avoid using VPNs

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.

Was this helpful?

How can we improve it?
Search
Clear search
Close search
Google apps
Main menu