Clear search
Close search
Google apps
Main menu

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

    Optimize your network for Hangouts

    We announced a new communications product, Hangouts, in May 2013. Hangouts will replace Google Talk and does not support XMPP.

    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.

    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.

    Final tips

    Peer-to-peer calling in classic Hangouts

    Video calls between two mobile clients use a direct peer- to- peer connection, which means audio and video data is sent directly between the devices to reduce network load. 

    Multiway calling and video calls using a browser use additional network resources to transmit data.  

    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.