Prepare your network for Meet video calls

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

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 following URI patterns using port 443.

Note: If you're using Google Meet hardware, please also review the networking requirements for ChromeOS.

For web traffic, APIs, feedback reports, logs upload, and connectivity setup patterns:

• https://*.google.com/*
• https://*.googleapis.com/*
• https://*.gstatic.com/* 
• https://*.googleusercontent.com/*

For live streaming patterns:

• https://*.googlevideo.com/*
• https://*.youtube-nocookie.com/*
• https://*.ytimg.com/*

Meet traffic is secured and encrypted, so there is no need to restrict traffic to the Google Workspace IP addresses.

However, if you have network constraints that require you to restrict traffic, you can allow access only to Meet’s media servers. These IP ranges are used exclusively for Meet so you can identify video meeting traffic used with your organization’s Google Workspace account and deprioritize Google Meet traffic from consumer accounts.

Allow access to Meet's media servers using the following set of IP ranges:  

• IPv4: 74.125.250.0/24
• IPv6: 2001:4860:4864:5::0/64

Notes:

• These IP ranges are only for media (audio and video) and don't correspond with the URIs listed above in Step 2.
• These IP address ranges apply only to Google Workspace Meet users. Participants who are not signed in to Google Workspace or signed in to a personal Google Account use various IPs addresses for Meet media traffic. Those IP addresses may change and are therefore not documented. 
• Consumer and Google Workspace Meet traffic use the same port ranges as described in Step 1. 

Your network should have enough bandwidth for concurrent HD video meetings, plus additional bandwidth for other needs, such as live streaming. If there’s not enough bandwidth, Meet lowers the video definition to fit the network constraints. If the bandwidth is insufficient to transfer video, an audio-only mode is used.

To calculate minimum bandwidth for participants and live streaming, multiply the average bandwidth per participant by the peak number of concurrent participants. 

The bandwidth used by Meet varies to provide the best experience on participants’ networks.

Average bandwidth per participant
Meeting type	Outbound	Inbound
HD Video	3.2 Mbps	1.8 Mbps
Audio only	12 Kbps	18 Kbps

 

Ideal bandwidth per participant
Meeting type	Outbound	Inbound
2-person HD video meetings	3.2 Mbps	2.6 Mbps
Group video meetings	3.2 Mbps	3.2 Mbps

Estimate peak number of concurrent participants

Determine the number of concurrent participants based on how important video calling is at each site, as shown in the following table.
 

Importance of video meetings	Peak number of concurrent video meetings
High	10–20%
Normal	1–4%
Low	0.01–0.5%

For example, if video 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 video 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
480p	1.5 Mbps
360p	1.0 Mbps
240p	0.5 Mbps	Results in a poor viewer experience and is not recommended

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

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

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

WMM best practices

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.

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 compelling reasons, such as a congested network, and are able to deploy and maintain an end-to-end QoS model in your network.  

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

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.

Note: We do not recommend using QoS in your Meet network. If you must control Meet bandwidth usage at the network level to reserve or limit traffic for Meet, see QoS best practices.