Zoom Meetings Hybrid Explainer

Zoom Meetings Hybrid Overview

This section provides an overview of the Zoom Meetings Hybrid service module, supported as a Zoom Node workload. For more information about Zoom Node, an overview of the platform is available at the end of this document in the Appendix.

Zoom Meetings Hybrid is an on-premises hybrid meeting solution that saves bandwidth by redistributing meeting media within a corporate network

Zoom Meetings Hybrid is an on-premises hybrid meeting solution that acts as an intermediary connection point between a Zoom client and the Zoom cloud. The solution multiplexes and redistributes a meeting’s audio, video, and screen sharing media streams with up to 400 connected participants within the same corporate network. This design reduces the number of external cloud media connections, which can significantly reduce external bandwidth consumption.

Zoom Meetings Hybrid supports two modes: cloud-hybrid and internal-only

Zoom Meetings Hybrid supports two modes of operation: a cloud-to-premises hybrid mode known as Selective Forwarding Unit mode (SFU), and an internal-only mode (iMMR) for non-cloud meetings. Meetings are configured for cloud-hybrid connections by default, but can be designated as internal-only when users schedule or edit a meeting. Both meeting types can also be supported by the same module simultaneously.

Cloud-hybrid mode connects users within your corporate network to the cloud through the hybrid module

In cloud-hybrid mode (SFU mode), users within your corporate network connect to the hybrid module as an intermediary connection point between their client and the cloud. The hybrid module multiplexes and redistributes a meeting’s audio, video, and screen sharing media streams between the users and the cloud.

Cloud-hybrid meetings do not affect cloud-to-client signaling connections

Although the Zoom Meetings Hybrid module can redistribute a cloud-hybrid meeting’s media, the module does not handle cloud-to-client signaling connections. Users connected to the Meetings Hybrid module will continue to establish a bandwidth-light signaling connection with the meeting’s cloud server for in-meeting data and operations, like starting a cloud recording or updating the participants list.

Warning

Client devices must have proxy or default route access to the Internet capable of reaching Zoom cloud services. HTTPS proxy is supported, but devices without access will be unable to connect to meetings.

Internal-only mode connects users to an on-premises meeting, and does not allow participants outside of the network to join

When a meeting is scheduled as internal-only, the hybrid module acts as an internal multi-media router (iMMR), multiplexing and redistributing a meeting’s audio, video, and screen sharing media between users within the corporate network. These meetings are isolated to the corporate network and cannot connect or cascade to cloud meeting servers or services, preventing external network participants or services like cloud recording from joining the meeting.

Internal-only meetings route both signaling and media connections through the hybrid module

Unlike the cloud-hybrid model, internal-only meetings route both media and signaling within the network to the hybrid module. This creates a complete on-premises meeting type, without the possibility of external connections.

Employees outside the corporate network can join internal-only meetings through VPN

Employees outside the corporate network can join internal-only meetings while connected to a VPN if the VPN server can communicate with the hybrid module across the corporate network. However, users must be signed into their company Zoom account to join.

For example, a remote employee is connected to the company’s VPN from their home network without split tunneling. So long as the user is signed into their company Zoom account and the connected VPN server can communicate with the hybrid module within the corporate network, the remote user can connect to an internal-only meeting remotely.

Meetings Hybrid can simultaneously support cloud-hybrid and internal-only meetings

Meetings Hybrid can simultaneously support cloud-hybrid and internal-only meetings, negating the need for separate deployments for each use case.

For example, a company has one hybrid module deployed within their network, with 400 connected users. In this scenario, 200 users can connect to cloud-hybrid meetings, with the remaining 200 users connected to internal-only meetings. For each connected meeting type, the Meetings Hybrid module will respect the intended connection routing: cloud-hybrid meetings will route media through the module and signaling to the cloud; internal-only meetings will route both media and signaling exclusively on-premises.

Zoom Meetings Hybrid keeps all media on-premises if no external participants are present and all users are connected to the same hybrid module

If users are connected to a cloud-hybrid enabled meeting through the same Meetings Hybrid module, but no external participants are present, the hybrid module will not transmit media between the Zoom Cloud. Instead, all meeting media will be kept on-premises and routed within the corporate network through the hybrid module. Meeting media will only leave the network after an external participant has joined from the cloud, or if a second hybrid module within the network connects to the meeting.

For example, a group of users within a corporate network are joining the same cloud-hybrid enabled meeting. All users are connected to the same hybrid module and all meeting media is being routed within the corporate network. Once an external user joins the meeting from the cloud, or a second hybrid module connects to the meeting, the hybrid module(s) will open a media connection with the cloud, and redistribute the meeting’s media to and from the cloud.

Note

Internal users can also establish external media connections if the hybrid infrastructure is at capacity.

Zoom Meetings Hybrid supports end-to-end encrypted meetings for both meeting modes

Zoom Meetings Hybrid supports end-to-end encrypted (E2EE) meetings in both cloud-hybrid and internal-only meeting modes. This provides an extra layer of security for confidential meetings, and can be paired with internal-only meetings for meetings demanding the highest levels of security available within the Zoom platform.

Customers can deploy multiple region-specific hybrid zones across their data centers

Zoom Meetings Hybrid supports multiple zone deployments, allowing customers to deploy separate hybrid environments for different locations or regions. When multiple zones are in place, users will connect to the closest hybrid module based on their ping time to available appliances.

For example, if a business has a New York and Los Angeles office, a single hybrid deployment in one location may cause latency or performance issues due to extended travel time. Instead, customers can deploy a hybrid environment for each specific location or region to improve the user experience. When a user attempts to connect to a meeting, the user’s client will ping available hybrid modules and will connect to the module with the lowest latency.

Zoom Meetings Hybrid does not replace Zoom’s Meeting Connector

Zoom’s Meeting Connector is a Zoom Node workload that offers a cloud-managed, on-premises solution for creating a meeting zone within your company’s data center, without cloud support or fallback. With Meeting Connector, all meeting servers and appliances are owned and maintained by your company, and must allow external connections for external participants to join your meetings.

Unlike Meeting Connector, Zoom Meetings Hybrid continues to utilize cloud meeting infrastructure in conjunction with hybrid appliances in your data center, and does not require hosting meeting servers or allowing external participants to connect to your data centers.

The following table outlines some of the key differences between these two products:

Capability	Meetings Hybrid	Meeting Connector
On-Premises Server	☑️	☑️
Supports Multiple Zones	☑️	☑️
Media Exclusively On-Premises	☑️ (While in iMMR Mode)	☑️
Cascade to Cloud	☑️
Users Can Join Through Cloud	☑️
Cloud Services (Recording, etc.)	☑️
Allows External User Connections		☑️

Zoom Meetings Hybrid Functionality

This section discusses the functionality and design of the Zoom Meetings Hybrid service module.

Zoom Meetings Hybrid is comprised of two components: a Selective Forwarding Unit/Internal MMR, and a Zone Controller Proxy

To deploy Zoom Meetings Hybrid within a network, two Zoom Node components are required: a Selective Forwarding Unit (SFU)/Internal MMR (iMMR), and a Zone Controller Proxy (ZCP). Refer to the Appendix at the end of this document for more information on service modules.

The SFU/iMMR operates like a power strip, redistributing media to connected Zoom clients

The Selective Forwarding Unit (SFU)/Internal MMR (iMMR) module is central to the Zoom Meetings Hybrid design. Similar to a power strip, the SFU/iMMR is a centralized network “plug-in” that distributes media to connected Zoom clients. However, the function of the SFU/iMMR module varies depending on the meeting type.

In hybrid meetings, the SFU/iMMR acts as the primary connection point for internal Zoom clients, multiplexing and redistributing meeting media between connected Zoom clients within the network and the cloud.

For internal-only meetings, the SFU/iMMR acts as a local multi-media router, centrally multiplexing and distributing media to connected users and other SFU/iMMR units (if connected) without the Zoom Cloud.

Each SFU/iMMR supports up to 400 standard definition or 200 high definition user connections per-module

Each SFU/iMMR module supports up to 400 concurrent, standard definition participants per-module, or up to 200 concurrent high definition (720p) participants. At maximum capacity for a single meeting, the SFU/iMMR module can reduce external bandwidth consumption by a ratio of 400:1 or 200:1, depending on meeting resolution.

A SFU/iMMR can support multiple meetings at the same time

The SFU/iMMR module supports simultaneous meeting connections, allowing one module to support multiple unique, concurrent meetings, including both cloud-hybrid and internal-only meetings.

For example, 400 users within a location are concurrently connecting to 25 different meetings in standard definition with external users present. With Zoom Meetings Hybrid, one SFU module can support connecting all users to their respective meetings, reducing the number of external media streams from 400 to 25. At an average of 1.2 Mbps per-media connection, the SFU module can save the campus approximately 450 Mbps of external bandwidth in this scenario.\

A SFU/iMMR can support cloud-hybrid and internal-only meetings at the same time

A SFU/iMMR module can simultaneously support cloud-hybrid and internal-only meetings, negating the need for separate deployments for each use case. For each connected meeting type, the hybrid module will respect the intended connection routing: cloud-hybrid meetings will route media through the module and signaling to the cloud; internal-only meetings will route both media and signaling exclusively through the on-premises hybrid module.

For example, 400 users within a location are concurrently connecting to three separate meetings in standard definition. Two meetings are cloud-hybrid with external users present, and 300 users from the corporate network are connected through the SFU/iMMR module operating in SFU mode. The third meeting is internal-only, with 100 users connected to the same SFU/iMMR module operating in iMMR mode.

In this example, users connected to the cloud-hybrid meetings have a bi-directional media connection with the SFU/iMMR module, and have independent, bi-directional signaling connections with the cloud. Meanwhile, users connected to the internal-only meeting have bi-directional signaling and media connections exclusively with the same SFU/iMMR module, which keeps all internal-meeting data on-premises and does not cascade to the cloud.

For cloud-hybrid meetings, the SFU/iMMR acts only as a forwarding device, and does not have access to any meeting or user keys

When connected to a cloud-hybrid meeting (SFU mode), SFU/iMMR modules do not require and do not have access to meeting encryption keys. Instead, the modules maintain media mixing roles as encrypted meeting media processors, incapable of accessing the contents of the media stream.

For internal-only meetings, the SFU/iMMR generates and distributes all encryption keys within the corporate network

When operating as a multi-media router for internal-only meetings (iMMR mode), the top-level SFU/iMMR in a meeting is responsible for generating and distributing in-meeting encryption keys. Encryption keys are generated and distributed using the same cryptographic methods as cloud-based MMRs.

SFU/iMMR modules cannot communicate with each other across a network when connected to a cloud-hybrid meeting

SFU/iMMR modules do not support cross-network (east-west) communication within a data center when connected to a cloud-hybrid meeting. All SFU-to-SFU communication for cloud-hybrid meetings must be routed through the Zoom cloud infrastructure (north-south) by design.

SFU/iMMR modules can communicate with each other across the network when connected internal-only meeting

Unlike with cloud-hybrid meetings, internal-only meetings support cross-network (east-west) communication due to the internal meeting design. Cloud-hybrid meetings require each SFU/iMMR module to subscribe to the “top” cloud MMR’s media feed; however, internal-only meetings do not utilize cloud media feeds. Instead, the first iMMR/SFU module to create an internal-only meeting is the “top” MMR, and additional SFU/iMMR modules subscribe to the top MMR feed, allowing for cross-network communication.

The Zone Controller Proxy module connects the SFU/iMMR to the Zoom Cloud

The Zone Controller Proxy module is responsible for connecting SFU/iMMR modules to Zoom’s cloud meeting infrastructure, when applicable.

During a user’s meeting connection process, Zoom web services sends a request between the Zone Controller Proxy and a cloud Zone Controller to fetch the meeting server information. This information is relayed from the Zone Controller Proxy to the SFU/iMMR, which will connect to the Zoom cloud for cloud-hybrid meetings, or initialize a meeting for internal-only meetings.

Deployments require at least two Zone Controller Proxies per location

Each geographic location Zoom Meetings Hybrid is deployed requires at least two Zone Controller Proxies for resiliency and stability.

For example, if a company is deploying Zoom Meetings Hybrid to their Los Angeles and New York offices, each location should deploy two ZCP modules at each location, totalling four.

If a SFU/iMMR module unexpectedly fails, users will failover to alternate connections when possible

Although unexpected, in the event a hybrid module fails (i.e., crashes) while users are connected, users will begin to failover to alternate connections if possible. These scenarios are described in the following three sections.

Users connected to a cloud-hybrid meeting will failover to an alternative SFU/iMMR module if available, and to the cloud as a last resort

If users are connected to a cloud-hybrid meeting through an SFU/iMMR module that abruptly fails, user clients will automatically attempt to failover to other SFU/iMMR modules available within the network. If other resources are at capacity or unavailable, user clients will establish independent cloud connections as a final failover solution.

Users connected to an internal-only meeting will failover to a different SFU/iMMR module if the failed module was not the top MMR

If users are connected to a internal-only meeting and their SFU/iMMR module fails, users will failover to alternative SFU/iMMR modules if available, providing that their SFU/iMMR was not the top-level MMR host of the internal meeting.

If the SFU/iMMR that started an internal-only meeting fails, the meeting must be restarted

Due to the network design for internal-only meetings, the SFU/iMMR module that initiates the meeting is designated as the top-level MMR for the meeting. If the top-level MMR of a meeting fails, quits, or leaves the meeting, the meeting will collapse and must be restarted. Top-level MMRs cannot failover to alternative hybrid resources.

Zoom Meetings Hybrid connections display as a “data center controlled by your Zoom account owner” within the client

When connected to Meetings Hybrid infrastructure, users will see that they are “...connected to the Zoom Global network… via a data center controlled by your Zoom account owner” within the client. Alternatively, users connected to cloud infrastructure will see the message they are “Connected to the Zoom Global Network.”

The following images display what users will see when connected to a Zoom Meetings Hybrid meeting compared to a cloud-based meeting.\

Zoom Meetings Hybrid uses Zoom’s standard firewall configuration and does not require special rules

Zoom Meetings Hybrid does not require any additional firewall rules or configurations outside of Zoom’s default recommendation. Media connections will continue to use UDP/TCP 8801 and TCP 443 (TLS 1.2) as standard ports for the service.

Note

Port separation for media (UDP 8801-8803) is supported. Ensure firewall rules are configured to include 8802 and 8803 if port separation is enabled.

Appendix: Zoom Node

This section provides a general introduction to the Zoom Node platform and its core concepts.

Zoom Node brings key parts of the Zoom service to your own data centers and offices

Zoom Node is a hybrid solution that integrates your data center servers with Zoom’s cloud to help deliver Zoom services to your offices.

Featuring a cloud-driven deployment model, Zoom administrators can dynamically and quickly deploy Zoom hybrid services to their data center servers from a centralized dashboard on the web. This dashboard additionally includes tools for service management, upgrades, log management, performance reporting, and a robust troubleshooting framework.

Zoom Node is a modular design, where you only deploy the service modules you need

Instead of requiring separate software for each hybrid service, Zoom Node is an “all-in-one” modular platform that allows companies to manage and deploy multiple hybrid services using one common framework.

Zoom Node achieves this modular design by installing the Zoom Node OS (a Linux-based operating system) onto enterprise datacenter servers, transforming them into Nodes. Once the software is installed, the Node registers to the Zoom Node Platform in the cloud and awaits installation of various service modules that provide Zoom service functionality

Zoom Node includes a feature-rich dashboard for service management, upgrades, alerts, troubleshooting, and more

As a central hub for managing Zoom Node deployments, the Zoom Node dashboard includes tools for service management, deployments, upgrades, log management, performance reporting, and a robust troubleshooting framework.

Service modules are the services that run on the Zoom Node OS, and are easily deployed through the web

Service modules are the service applications that run on the Zoom Node operating system, allowing services to function. Zoom administrators assign services to nodes through the Zoom Node dashboard on the web portal. After assigning the service to a Node, the Zoom Node Platform pushes the chosen service module to the Node and installs automatically. Once installation is complete, the Node endpoint is ready for use with its designated hybrid service(s).

Each Zoom Node can support up to four service modules

Each Zoom Node appliance can support up to four service modules per machine, except for the Zoom Phone Local Survivability module. Additional Nodes can be created and linked for additional requirements or resiliency.

For example, a company is deploying Zoom Meetings Hybrid across several data centers, beginning with New York. Each data center is equipped with several Zoom Node endpoints connected to the Zoom Node Platform, but none has been assigned a Node service for functionality, as seen in the following image.

Once the company is ready to deploy Zoom Meetings Hybrid within their network, an account admin deploys one Zone Controller Proxy service, and three SFU/iMMR modules to Nodes 1 and 2. The admin also deploys an extra SFU/iMMR module to the third Node as a buffer. The Zoom Node Platform pushes and installs all Node services to each Node endpoint, and after the installation is complete, Zoom Meetings Hybrid ready for use as seen in the following image.

Zoom Node supports end-to-end automated PKI certificate generation (Auto-PKI)

Zoom Node includes end-to-end automated public certificate management through DigiCert. All costs for generating and renewing certificates are paid by Zoom, but Zoom does not handle or have access to customer's private keys through this process.

Customers with an existing certificate strategy can choose to generate, renew, and support certificates manually with a certificate authority of their preference, but these costs will not be paid for by Zoom. Customers that intend to use an alternative certificate authority should speak with their account team in advance.

Each Zoom Node has a dynamic DNS entry using the account’s Vanity URL: *.zoomonprem.com (Auto-DNS)

Zoom Node automatically generates dynamic DNS entries for each server under the *.zoomonprem.com domain using the host account’s existing Vanity URL, e.g. success01.zoomonprem.com.

This system simplifies firewall management when connecting to Zoom Node deployments used by other Zoom customers. Individual customers will no longer require firewall rules to connect to another Zoom Node customer, but can instead approve the entire zoomonprem.com domain using wildcard values.

Zoom Node runs on virtual machines

Zoom Node is designed to run on server-grade hardware, using virtual machines, installed with the hardened Zoom Node operating system image. All services will require static internal IP addresses, with some services requiring public IPs for external connectivity.

The hardware requirements and specifications will be unique to your hybrid deployment goals. Please refer to your account team for more information on identifying your organization’s needs for a hybrid deployment.

Zoom Node is not for every customer

Every enterprise has unique requirements when it comes to unified communication services. These needs must be carefully considered before making a decision to deploy a hybrid environment. In most cases, the traditional Zoom cloud configuration is the optimal solution for most companies; however, there are organizations that benefit from hybrid configurations. Organizations should be thorough in considering the implications of establishing and maintaining a hybrid environment.

Scaling can be difficult and expensive to manage

Scaling the hardware to support a large number of users in hybrid environments can be costly. Depending on the services deployed, supporting 10,000 users could require between 7-13 Zoom Nodes, while supporting 100,000 users may require between 60-120 Zoom Nodes.

Managing, maintaining, and supporting the hardware and/or hypervisor infrastructure required for Zoom Node also creates additional overhead for any organization and should be heavily considered when examining hybrid deployments.

Security advantages are limited

Zoom Node does not offer additional encryption methods or major security advantages over the native Zoom cloud service, apart from the potential to serve as a specialized web proxy or local log residency.

Hybrid deployments also require additional firewall rules and configurations to make Node endpoints available with external services. Network security teams should be mindful of these additional firewall and security requirements when considering deploying hybrid environments.

Hybrid environments and VPNs require configurations

Remote employees may require a VPN connection or a split-tunnel configuration to route their meeting traffic to Zoom Node services if desired. This increase in traffic can potentially overwhelm the VPN infrastructure if it cannot handle the additional bandwidth being sent and received. Careful planning is required when combining hybrid services with remote workers and remote network infrastructure.

Sharing server logs requires careful consideration

Although maintaining local control over Zoom Node logs and records is a component of hybrid deployments, this feature can be obstructive when troubleshooting hybrid infrastructure.

Service logs are maintained locally by default, and include data, diagnostics, and other information not available to Zoom for viewing. However, in order to effectively troubleshoot hybrid configurations and quality concerns, hybrid data logs are required to be shared with Zoom for troubleshooting purposes. Zoom Node offers a secure log file upload service through the web portal at customer discretion, but uploading these logs can expose service metadata that is otherwise not shared with Zoom in hybrid deployments. This data may include names of participants joining locally, Zoom version number, operating system information, and more.