Prepare network for Beam 3D video meetings

In addition to the network settings required for standard video meetings (regardless of your provider), Google Beam requires specific network support to enable 3D meetings. This page explains the network requirements and how to validate that your network settings meet them to ensure Beam 3D meetings are a smooth and high-quality meeting experience.

Bandwidth and network performance

To run 3D video conferencing meetings, ensure your network meets the following requirements:

Requirement Value

Minimum Sustained Bandwidth

50 Mbps (upload and download) for 3D video conferencing

3.6 Mbps (upload and download) for standard video conferencing (HD)

1.7 Mbps (upload and download) for standard video conferencing (SD)

Link speed

At least 1Gb/s

Latency

100 ms or less (to or from Beam endpoints)

Jitter

40 ms or less

Packet loss

1% or less

Your network should have enough bandwidth for multiple HD video meetings and extra bandwidth for other needs, such as live streaming. Number of participants, screen sharing, and other factors also affect bandwidth usage.

If your available bandwidth falls below 50 Mbps, the quality of 3D meetings can be reduced. Here's a breakdown of the potential impact:

  • Around 10 Mbps: 3D video can be degraded.
  • Around 5 Mbps: 3D video is turned off entirely, audio quality can be degraded, and the frame rate can be reduced.

Jitter

Inconsistency in arrival times can make it difficult for the receiving end to smoothly reconstruct the original data stream. Jitter above 40 ms can lead to choppy video, distorted audio, and dropped connections.

Packet loss

Packet loss higher than 1% can manifest as choppy video, missing audio segments, or even dropped connections.

Network architecture and NAT requirements

Your HP Dimension devices communicate with Google services using outbound internet connections. To ensure optimal performance, security, and bandwidth isolation, configure your network according to the following rules:

  • Dedicated VLAN: Place all Beam-enabled devices on a dedicated internal Virtual Local Area Network (VLAN) and apply the specific egress firewall rules listed later in this page. Isolating the devices shields Beam's 3D spatial video streams (up to 50 Mbps up/down per active device) from latency spikes and packet loss caused by traffic on the general office LAN.
  • NAT and IP addressing: Beam-enabled devices can operate on standard internal subnets behind IPv4 Network Address Translation (NAT) with internet access. A 1:1 public IP address isn't required.
  • No VPN or proxy: Avoid using VPNs or proxy servers for Beam traffic. Both add latency and can cause a reduction in video and audio quality.
  • Network redundancy: For added resiliency, use network redundancy (automatic failover to secondary in case the primary fails) on the WAN link.

IP address configuration

Note: This section only applies to the HP Dimension. The touchscreen has its own DHCP network settings and you shouldn't change them.

To assign IP addresses, use automatic DHCP or static IPv4 assignment. Beam only supports IPv4 and IPv4/IPv6 mixed mode.

  • DHCP (default and recommended): By default, Beam-enabled devices automatically get an IP address, subnet mask, default gateway, and DNS server addresses from DHCP upon boot.
  • Static IP assignment: If your network policy requires static IP addresses, you can manually configure static network parameters on the device during initial enrollment and setup. Static assignment requires a reserved IPv4 address, subnet mask, and default gateway.

Firewall rules and port requirements

Important: The default domain IP ranges used by Google APIs and services are allocated dynamically and change often. Before opening specific egress ports, verify that your network firewall permits outbound connections to Google's official IP address ranges:

After confirming endpoint accessibility, configure the egress port rules listed in the following table:

Ports Type Purpose
53 UDP DNS resolution
80 TCP and UDP HTTP web traffic
443 TCP and UDP HTTPS (web traffic and user authentication)
3478 TCP and UDP WebRTC and TURN
19302–19309 UDP WebRTC

Google IP address ranges

If your organization restricts outbound traffic or performs Server Name Indication (SNI) inspection, configure your firewall or proxy to allow the following IP address ranges, ports, and SNI hostnames:

SNI or hostname Ports and protocol IPv4 and IPv6 range Purpose or service
*.googleapis.com TCP and UDP 443 N/A Google services
projectstarlinecallaccess.pa.googleapis.com
projectstarlinesession-pa.googleapis.com
TCP and UDP 443 N/A Google Beam service
logging.googleapis.com TCP and UDP 443 N/A Logging
monitoring.googleapis.com TCP and UDP 443 N/A Monitoring
storage.googleapis.com TCP and UDP 443 N/A Storage
clients3.googleapis.com TCP and UDP 443 N/A Device management
workspace.turns.goog TCP and UDP 443 74.125.250.0/24
2001:4860:4864:5::/64
Workspace media relay
meet.turns.goog TCP and UDP 443 142.250.82.0/24
2001:4860:4864:6::/64
Meet media relay
N/A UDP 3478 74.125.247.128/29
2001:4860:4864:4:8000::
TURN and STUN services
N/A UDP 53 8.8.8.8, 8.8.4.4 Google DNS

Set up standard video conferencing settings

Each video conferencing platform requires access to certain ports and endpoints. If you haven't already, set up your network to allow access.

Click the tab that corresponds to your license.

Google Beam for Meet

Follow the instructions in Prepare your network for Meet meetings and live streams to set up the network for Meet.

Google Beam for Zoom

Follow the instructions in Firewall Configuration for Zoom Rooms to set up your network for Zoom.

Beam is built on ChromeOS and requires your network to also meet ChromeOS networking requirements. Review the ChromeOS networking requirements at Set up a hostname allowlist for Chrome devices.

Set up touchscreen settings

The Poly TC10 touchscreen used with the HP Dimension has its own requirements. Allow the hostnames listed in the HP documentation for Poly Lens network devices to ensure that the touchscreen works properly.

Testing your network

Network latency

To measure your network latency and ensure it meets the requirements for optimal video conferencing, follow these steps:

  1. Enable ICMP (if necessary): Ensure that ICMP (Internet Control Message Protocol) is enabled on your network. Most networks have it enabled by default, but if you're on a restricted network, you may need to check with your network administrator.
  2. Run the ping command: From a computer on the same wired network connection you'll be using for video conferencing, open a terminal or command prompt and run the following command:

    > ping 74.125.247.128
    PING 74.125.247.128 (74.125.247.128): 56 data bytes
    64 bytes from 74.125.247.128: icmp_seq=0 ttl=56 time=21.706 ms
    64 bytes from 74.125.247.128: icmp_seq=1 ttl=56 time=14.054 ms
    64 bytes from 74.125.247.128: icmp_seq=2 ttl=56 time=36.137 ms
    64 bytes from 74.125.247.128: icmp_seq=3 ttl=56 time=19.932 ms
    64 bytes from 74.125.247.128: icmp_seq=4 ttl=56 time=19.043 ms
    

    Look for the time= values in the output. These represent the latency in milliseconds. It's best to consider the average or a typical value, rather than a single value.

  3. Verify latency: For the best video quality, ensure your latency is less than 100 ms to the nearest Google endpoint. If your latency consistently exceeds this threshold, it could negatively impact your video conferencing experience.

Network routing

You can use the traceroute command to trace the network path to Google's endpoints. This helps identify potential bottlenecks or unnecessary hops. Run the following command from a computer on the same wired network you'll be using for video conferencing:

> traceroute 74.125.247.128

This shows you the route your network traffic takes to reach a Google server. Ideally, you want to minimize the number of hops between your local network and your internet service provider (ISP). A large number of hops can indicate a less efficient route and potentially higher latency.

Another helpful tool to monitor hints of congestion is mtr, which behaves like a more useful version of traceroute. This tool can help identify potential problematic hops between the machine this is running on and the destination, to help disambiguate between problems inside a corporate network and problems with an ISP. Each hop is given averages and standard deviations on response time, which can help to identify potentially congested links.

Here is some sample output:

                                                  My traceroute  [v0.96]
hostname ([example]) -> 74.125.247.128 (74.125.247.128)
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                   Packets               Pings
Host                          Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.  100.115.92.25             0.0%   195    1.0   0.6   0.2   2.0   0.3
 2.  192.168.4.1               0.0%   195    2.7   3.6   1.9   7.9   1.2
 3.  192.168.1.254             0.0%   195    4.2   3.6   2.5   9.9   0.9
 4.  [example]                 0.0%   195    4.3   4.5   3.0   8.3   0.9
 5.  76.197.98.82              0.0%   195    5.1   4.6   2.9   9.4   0.9
 6.  32.130.92.48              0.0%   195   21.2  23.2  19.9 360.4  24.3
 7.  32.130.20.60             80.0%   195   21.4  21.2  19.9  24.8   1.1
 8.  32.130.20.246            82.5%   195   21.7  21.5  20.4  24.0   0.9
 9.  32.130.26.105             0.0%   195   23.4  21.9  19.7  29.9   1.1
10.  108.170.231.46            0.0%   194   22.4  23.0  21.3  42.4   2.0
11.  142.250.231.183           0.0%   194   22.0  22.0  20.5  32.2   1.5
12.  74.125.247.128            0.0%   194   22.5  22.7  21.2  29.1   0.9

For mtr installation information, go to the link for your operating system: Windows, Mac, Linux (usually installed using a package manager as mtr package).