Clear search
Close search
Google apps
Main menu

If your organization uses for video calls, visit the classic Hangouts Administrator Help Center.

Optimize your network for Hangouts Meet and classic Hangouts

Use this guide to create and generate a network plan when deploying Google Hangouts Meet or classic Google Hangouts.

This will help your network provide the bandwidth and performance required for video meetings using Hangouts Meet or classic Hangouts.

What’s covered Networking concepts for Hangouts Meet or classic Hangouts deployments
Audience Google partners, administrators, and network engineers
IT environment Network infrastructure
Deployment phases All
  • When deploying Hangouts Meet or classic Hangouts, bandwidth planning is vital
  • Concurrent usage estimates are required
  • Enable UDP ports 19302 to 19309
  • Enable TCP and UDP ports 80 and 443
  • Eliminate network bottlenecks
  • Use the Chrome Connectivity Diagnostics tool to test networks


Although most G Suite services and deployments don’t have a large network impact, real time video meetings can require large amounts of additional bandwidth.

Create a network plan

Use this guide to estimate your network’s additional bandwidth requirements and determine how to best manage related network issues when introducing Google Hangouts Meet or classic Hangouts. 

These solutions are scalable to networks of all sizes.

Step 1: Conduct a user survey 

Conduct a user survey (such as this example) to gauge your users’ video meeting experience, and to understand if your network resources are sufficient, or need improvement.

Step 2: Determine your usage and bandwidth requirements

Because bandwidth requirements and availability can change, we recommend that you do the following:
Note: This is only a starting point. As more people use video calls and spend more time on those calls, bandwidth usage and requirements may increase.
  1. Evaluate the number of concurrent Hangouts connections in an office to determine if bandwidth upgrades are required.
  2. Estimate your bandwidth requirements using the following equation: 
    Br = Bh x Nu
  3. Using the Admin SDK Reports API, run a pilot test to collect video bandwidth data for Meet, Hangouts (and if used, Google Chrome devices for meetings). 
  4. Use this data to predict the number of concurrent video call users in a given time period.


Br = Bh x Nu

  • Br—Total peak required bandwidth 
  • Bh—Bandwidth per Meet or Hangout connection
  • Nu—Number of concurrent users participating in any video call, at a given time, per location.

Bh bandwidth changes based on the user’s configured video quality settings and any automatic changes made by the Hangouts system. Use the following guidelines to estimate Bh bandwidth consumption per video call:

Scenario Bandwidth*
Minimum bandwidth required for video calls 
  • Outbound from the participant: 300 Kbps
  • Inbound to the participant: 300 Kbps
Recommended bandwidth for 2 person video calls
  • Outbound from the participant: 3.2 Mbps
  • Inbound to the participant: 2.6 Mbps
Recommended for video calls of more than 2 people
  • Outbound from the participant in all situations: 3.2 Mbps
  • Inbound to the participant with 5 participants: 3.2 Mbps
  • Inbound to the participant with 10 participants: 4.0 Mbps

*These measurements are based on average across various networks. The actual bandwidth consumption for your network may vary. We recommend Google recommends a thorough test plan to ensure these guidelines give optimal performance in your network. 

Step 3: Calculate usage and bandwidth requirements

Use a table, such as the following example, to calculate total usage and bandwidth requirements. This table only considers Hangouts traffic, not the bandwidth used by other network apps or services. 
The final column (Deficit/Excess) shows the amount of excess or required bandwidth at a given site. The calculations are based on recommended quality Hangouts and the bandwidth requirements mentioned in Step 2.
Site Users B/W Mbps Avg Network Utilization Available B/W Mbps Avg User Concurrency (%) Video Call Consumption


A 80 30.00 30% 21.00 2.00 4.16 16.84
B 100 60.00 40% 36.00 5.00 13.00 23.00
C 220 70.00 18% 57.40 2.00 11.44 45.96
D 300 30.00 28% 21.60 7.00 54.6 (33.00)
E 320 15.00 75% 12.75 6.00 49.92 (46.17)
F 318 100.00 12% 88.00 2.00 16.54 71.46 

The example data for “Site “A” represents:

  • 80 users and 30 Mbps total bandwidth 
  • 30% of the bandwidth is used on average 
    • Available B/W Mbps— Leaves 21 Mbps bandwidth available on average
    • Average User Concurrency—Meet or Hangouts is being used, on average, by 2% of the users at any given time. 
      Video Call Consumption— 2% concurrency of recommended quality Hangouts would require 4.16 Mbps of bandwidth because 2% of 80 users is less than one user. This leaves 1.98 Mbps of bandwidth available on average. Additionally, there’s sufficient bandwidth available for the nearest whole number of users (2 in this case) to conduct a recommended quality Hangout. In other words, this site shouldn’t require a bandwidth upgrade. 

The example data for Site “D”, however, represents:

  • 300 users and a 30-Mbps connection 
  • An average utilisation of 15%

This site will likely require a bandwidth upgrade on the basis of 7% concurrency of recommended, quality video calls.

Create a test plan

Create a test plan (see steps for key areas of focus) to gather the data needed to make an informed, capacity development plan.

Step 1: Choose the trial users

Choose the users for the trial who will adequately help you evaluate video call usage. We recommend including 5–10% of your users. Include people from different locations; usage can vary considerably between sites. For example, include teams from HR, Finance, and Legal departments that independently operate in the same country, but work together, internationally.

Step 2: Gather usage data for the trial users

Because video call usage data is reported for an entire G Suite account, turn on Hangouts Meet or Hangouts for the trial users only. This option gathers data for your test group only, allowing you to make reliable decisions about capacity planning. 
  1. Turn video calling on only for the users in your test group.
    1. Turn Meet on or off
    2. Turn Hangouts on or off
  2. Gather video call usage data using one of the following methods:
    • Use “Reports” in the G Suite Admin console to gather basic video call usage.
    • Use the Admin SDK Reports API to gather detailed data. This Application Programming Interface (API) retrieves usage statistics for video calls, as shown below.

​Use the Admin SDK Reports API data

The Admin SDK Reports API  exposes the following data:

Parameter Notes

Total number of video calls attended by users on the date of the report.

Note: Two people participating in a video call is counted as 1 video conference and 2 video calls.


Total number of minutes domain users spent attending video calls on the date of the report.

Note: External participants (people outside your domain) are not counted.


Total number of video conferences held on the date of the report.

Note: Two people participating in a video call is counted as 1 video conference and 2 video calls.

num_7day_active_cfm_devices The number of Chrome devices for meetings that were active in the 7 days before the date of the report.

Retrieve usage data

The following Google Apps Script code snippet can be used to retrieve usage data. The snippet outputs data to the Apps Script Logger, but this can easily be expanded to output elsewhere.

// Specify trial start date

var startDate = new Date("2016, JANUARY, 1");


// Specify trial end date

var endDate = new Date("2016, JANUARY, 19");


// Date calculations

function addDays_(date, days) {

  var newdate = new Date(date);

  newdate.setDate(newdate.getDate() + days);

  return newdate;



function getData() {

  // These are the descriptions and names of the requested API fields

  var parameters = [

      ['Num calls: ','gplus:num_video_calls'],

      ['Call minutes: ','gplus:total_video_call_minutes'],

      ['Num conferences: ','gplus:num_video_conferences'],

      ['Seven day active CfM: ','gplus:num_7day_active_cfm_devices']


  var requestData = [];

  parameters.forEach( function(parameter) {



  var pageToken, page;

  while (startDate < endDate) {

    do {

      var dateString = startDate.toISOString().slice(0, 10);

      page = AdminReports.CustomerUsageReports.get(dateString, {

        parameters: requestData.join(','),

        maxResults: 500,

        pageToken: pageToken


      pageToken = page.nextPageToken;

      var reports = page.usageReports;

      if (!reports) {

        return null;


      reports.forEach(function(report) {

        var parameterValues = getParameterValues(report.parameters); 

        if (!parameterValues){

          return null;


        var daySummary = '';

        parameters.forEach(function(parameter) {

          if (parameterValues[parameter[1]]) {

            daySummary = daySummary + parameter[0] + ': ' + parameterValues[parameter[1]] +

              '. ';





    } while (pageToken);

  startDate = addDays_(startDate,1);






 * Gets a map of parameter names to values from an array of parameter objects.

 * @param {Array} parameters An array of parameter objects.

 * @return {Object} A map from parameter names to their values.


function getParameterValues(parameters) {

  if(!parameters) {

    return null;


  return parameters.reduce(function(result, parameter) {

    var name =;

    var value;

    if (parameter.intValue !== undefined) {

      value = parameter.intValue;

    } else if (parameter.stringValue !== undefined) {

      value = parameter.stringValue;

    } else if (parameter.datetimeValue !== undefined) {

      value = new Date(parameter.datetimeValue);

    } else if (parameter.boolValue !== undefined) {

      value = parameter.boolValue;


    result[name] = value;

    return result;

  }, {});



Step 3: (Alternative) Use data from existing systems

Use your data from existing video systems

You can also use your existing resources and tools, if available, to predict Hangouts Meet and Hangout video call usage. For example, you can use data from an existing video conferencing or real- time video collaboration system to predict Hangouts Meet usage. 

These sources can underestimate usage, however, because video call usage tends to increase when Hangouts Meet or Hangouts is deployed.

Use calendar event and resources data

Calendar events and resource bookings can indicate how frequently users in different locations or buildings interact. Use this data to predict potential video call usage.

Use office or location geographic distribution data

We recommend including users in the same location. Although it can appear that users in the same building or location might not use video meetings, that assumption is often incorrect. 

Discover the weakest link in the network

Discover the network network infrastructure bottlenecks when planning a Hangouts Meet or Hangouts deployment. This discovery provides the highest return on investment (ROI) upgrades for video traffic. 

For example, to assess average usage and available headroom, inspect each device in the network path from users to the Internet; see the following network architecture:

  Average utilization (Mb/s) Device’s maximum throughput (Mb/s) Headroom
Possible recommended concurrent sessions Possible minimal quality sessions
A 14.6 40.0 25.4 9 84
B 54.5 100.0 45.5 17 151
C 70.0 100.0 30.0 11 100
D 10.0 100.0 90.0 34 300
E 17.4 20.0 2.6 1 8

In this example, device E is the first device that reaches its maximum throughput.

There’s 2.5- Mb/s headroom available on this device; it reaches saturation with 1 recommended performance Hangouts Meet or Hangouts video call. Removing or upgrading that device allows over 10 participants to join video calls at recommended levels.

Minimize latency between clients and Google

Minimizing round trip latency between Hangouts Meet or Hangouts clients can also greatly increase video call quality. For example:

Recommended latency < 100 ms
Acceptable latency < 400 ms
Poor latency > 400 ms 


Step 1: Measure your network latency

  • Use Google’s Chrome Connectivity Diagnostics extension to measure latency between your clients and Google. 
  • You can also use the interface to test WebRTC latency. WebRTC is an open project for integrating real- time communication capabilities directly into browsers using simple APIs. Google uses webRTC for Meet/Hangouts communication when using Google Chrome.

Step 2: Use UDP (not TCP)

Use the User Datagram Protocol (UDP) for video call communication, because it significantly reduces latency compared to Transmission Control Protocol (TCP). Although Hangouts Meet or Hangouts can use either TCP or UDP, TCP requires significant overhead.

For example, UDP allows video streams to move as fast as possible by ignoring dropped packets. If your existing network infrastructure doesn’t offer a route for UDP traffic from client to Internet egress, changes may be required.

TCP connections, however, require additional time and bandwidth to send packet responses, arrange packets in order, and wait for packet retries if a failure occurs. Although TCP is preferred for most network traffic, it causes too much latency for real- time video call communication.

Note: TCP port 443 is still required even when using UDP. Port 443 is used for media traffic in the video meetings.

Step 3: Proxies and packet inspection

To use UDP, a route for outbound traffic to the Internet must go around or through any proxy infrastructure. This is because none of the current major browsers support routing UDP traffic via proxy.

Although Hangouts Meet or classic Hangouts can operate over TCP (with greater latency than UDP), we still recommended bypassing any proxy infrastructure, especially if the proxies perform any packet inspection. Any form of proxying introduces latency, and packet inspection latency is often high enough to prevent video calls from functioning. Packet inspection of video traffic also yields little benefit, because automated scanning tools are unable to reconstruct data from the media stream.

Step 4: Use DNS resolution close to the user

Use DNS resolution as close to the user as possible to minimize latency

DNS resolution is used  to determine the video call users’ location, which allows the Google system to select the optimal data center to minimize latency. If video data is needlessly sent from a distant location, latency increases and the video call quality is poor.

Step 5: Open the outbound UDP and TCP ports

Outbound UDP/TCP traffic must be permitted. Our systems respond on the same port used for the outbound traffic, which allows firewalls to correctly and securely handle Hangouts Meet or Hangouts traffic.

We recommend opening the following ports to allow outbound traffic. Because UDP is preferable to TCP for performance, Hangouts Meet or Hangouts uses the following order of preference for attempting to connect to Google:

1 A UDP connection from the participant to Google on ports 19302 through 19309
2 A TCP connection from the participant to Google on ports 19305 through 19309
3 A UDP or TCP connection from the participant to Google on port 80
4 A UDP or TCP connection from the participant to Google on port 443 (SSL)

Note: Inbound ports don’t need to be opened through firewalls.

Step 6: Set a custom UDP port range

Although Hangouts Meet and classic Hangouts video calls default to the UDP port range 19302-19309, you can use custom ports for network environments where these ports are already utilized.
  1. Sign in to your Google Admin console.

    Sign in using your administrator account (does not end in

  2. Click Device management.
  3. On the left, click Chrome management.
  4. Click User settings.
  5. On the left, select the organization that contains the devices whose settings you want to change.
  6. Scroll down to Network Settings. Learn more
  7. Under WebRTC UDP Ports, specify the ports used by Chrome when creating WebRTC connections.
  8. Click Save.

Note: Only UDP ports can be customized. TCP ports cannot be customized since they are used if Media Hangouts traffic falls back to TCP or SSLTCP.

Learn more about managing device settings.

Final tips

Peer-to-peer video meetings

Video meetings between participants may use a direct peer-to-peer connection, which means audio and video data is sent directly between the devices to reduce network load. This only applies after the video meeting has started and Google has determined it is more efficient than not using peer-to-peer.

Learn more

Adjust video quality to reduce bandwidth use


Hangouts uses multiple metrics to estimate bandwidth use during a video call and automatically adjust video call quality settings, if necessary. This process allows video calling to function effectively while sharing available bandwidth with other network services.

For example, if bandwidth is available, Meet and Hangouts increase video quality. If network congestion is detected, video quality is automatically lowered until congestion is not detected or the minimum video quality is reached.

User adjustments in a video meeting

Users can limit video quality to reduce their bandwidth use, or allow the Hangouts system to automatically adjust their video quality based on current network conditions.

Note: G Suite administrators can’t control client bandwidth consumption. 

Don’t filter Google IP addresses or URLs

Don’t filter Google traffic or apply Quality of Service (QoS)-based URLs and IPs. If filtering is required, use a proxy .pac file containing current Google service URLs and Google IP addresses (both subject to change without warning) is recommended.

We don’t maintain a list of URLs and IPs explicitly used for video calls, because they may change at any time. Google URLs and IPs are pooled resources that can be re-allocated to different Google services without notice. 

Don’t use internal QoS for Meet or Hangouts traffic

Don’t use internal QoS for Meet or Hangouts video call traffic. QoS is difficult, complicated, and typically yields little benefit. 

Hangouts’ built-in bandwidth estimation may not work correctly with QoS implemented in the network, thereby removing the benefits of this adaptive technology. Separating Hangouts traffic from other Google traffic can also be difficult. 

Ideally, Hangouts traffic will be using UDP and can’t easily be proxied; adding complexity to the task of tagging packets.

Was this article helpful?
How can we improve it?
Sign in to your account

Get account-specific help by signing in with your G Suite account email address, or learn how to get started with G Suite.