Cisco Meeting Server alternative for air-gapped networks

What an air-gapped video platform must satisfy

A disconnected video platform has to work without a license server, a cloud registration or a public certificate authority, and every change that enters the network has to be verified. The six requirements below connect the platform design to the supply chain and remote access controls that regulated operators already answer to.

Where Cisco Meeting Server meets the constraint and where it creates friction

Which open-source options fit an air-gapped network

Jitsi Meet and BigBlueButton compared for disconnected use

This table compares Jitsi Meet and BigBlueButton 4.0 on the requirements that matter once servers sit on a disconnected network. Cells marked to confirm are open items to test in your own pilot build. Neither platform needs a license server, but BigBlueButton 4.0 must be installed fresh because direct upgrades from earlier versions are not supported.

How to deploy Jitsi or BigBlueButton inside the boundary

This sequence takes a classified or disconnected network from an empty enclave to a self-hosted Jitsi or BigBlueButton server that serves internal users, with every package verified on import and a documented way to take updates across the boundary.

1. Define the internal domain and certificate authority

   Your network or security team chooses an internal DNS name for the meeting service and issues its certificate from your internal certificate authority, which the security team controls. Jitsi's handbook states that HTTPS with a proper domain certificate is necessary for working audio and video and warns that self-signed certificates cause problems, especially on mobile clients, so confirm that every client device trusts the internal root before you go further. Done means the name resolves inside the enclave and a browser on a managed client loads the certificate chain without warnings.

2. Build the offline mirror in a staging enclave

   In a staging enclave that has controlled access to the internet, the platform team downloads the Jitsi Docker images or Debian and Ubuntu packages, or the BigBlueButton 4.0 install files and their dependencies, into a local repository. Ask the vendor or project which release you should pin, and record the exact build identifier, for example the Jitsi stable build tag you select. Done means the mirror holds a complete, versioned copy of everything the install needs, with a manifest listing each file.

3. Verify checksums and signatures on import

   Before anything crosses into the classified or disconnected network, the security team compares the checksum and signature of every artifact against values from the project's published release records, then repeats the check after transfer on the target side. This is the practical control behind the supply chain expectation in NERC CIP-013-2 for verifying software integrity and authenticity, and it applies to every patch you carry across the boundary. Done means a signed import log shows each artifact passed verification on both sides of the transfer.

4. Install the stack with no outbound calls

   The operations team installs the chosen stack from the local mirror on servers that have no route to the internet. For Jitsi, that means the web front end, Prosody, Jicofo and Jitsi Videobridge, optionally Jibri and Jigasi. For BigBlueButton, install on a clean Ubuntu 24.04 server with bbb-install.sh and the local repository, because BigBlueButton 4.0 requires a clean install and direct upgrades from 2.6, 2.7 or 3.0 are not supported. BigBlueButton needs at least 16 GB of RAM with swap, 8 CPU cores and 500 GB of disk for recordings (50 GB without recording). Done means services start and a firewall capture shows no egress attempts during startup.

5. Configure internal authentication

   Decide who may create rooms and set the method in the deployment configuration. Jitsi's Docker guide lists internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid mode, all set through the .env file. The Jitsi handbook marks the older secure domain method as deprecated for new installs and recommends JWT token authentication with a separate anonymous domain for guests. For BigBlueButton, every API call must carry a checksum made with the shared secret, so keep the secret out of any web page. Greenlight v3 can use OpenID Connect against an internal identity provider. Done means an unauthenticated user cannot create a room and a test account can log in through the chosen method.

6. Open media ports on the internal network

   Open the ports the media path needs only between the internal subnets that require them. Jitsi needs 80/TCP and 443/TCP, with 10000/UDP for media, and 5349/TCP and 3478/UDP are optional fallbacks. BigBlueButton needs TCP 80 and 443 and UDP 16384 to 32768, and its documentation recommends a TURN server for users behind restrictive firewalls. Confirm the bandwidth available internally, since BigBlueButton 4.0 lists 250 Mbit/s symmetrical. Done means the firewall rule set matches the port list in your change record and no other inbound media ports are open.

7. Test media paths and record the baseline

   Run test calls from each client segment that will use the service, including any room system or device on a separate VLAN, and confirm audio, video and screen sharing work in both directions. For BigBlueButton, test a recording and confirm it saves to the expected disk. Save the configuration, version identifiers, certificate fingerprints and test results as the baseline for the accreditation package. Done means every segment passes the test script and the baseline is stored in the controlled repository.

8. Set a documented update cycle by offline transfer

   Write the update procedure before go-live: how new releases are assessed, which staging enclave downloads them, how they are verified and transferred, and which change window applies. Because BigBlueButton 4.0 moved to a clean-install model for its major version, plan major upgrades as a new server build rather than an in-place change. Ask the vendor or project for its release and support policy, and confirm which maintenance branch you will follow. Done means an approved runbook exists and one dry-run update has been completed through the same transfer path.

How updates reach an isolated video server

Evidence assessors and auditors ask for

An offline video deployment is judged on what it can show, not only on what it runs. The cards below list the records that tie a Jitsi or BigBlueButton server to its boundary, its approved software and its change history. DeployOpen prepares these artifacts, but independent auditors and certification bodies decide any assessment outcome.

Questions buyers ask before moving off Cisco Meeting Server air-gapped

How a fixed-scope air-gapped engagement runs

A written scope moves the work through discovery, design, staging, pilot, cutover and handover, so the client knows what is delivered, what it needs to provide and how each phase is accepted before the next one starts.

1. Confirm scope, boundary and client responsibilities

   DeployOpen and the client agree in writing which meeting services, users, rooms, SIP and endpoint integrations, and network zones are in scope, and who owns each. The client names a sponsor, a security approver, a network owner for the enclave and a CMS administrator, and confirms who may approve media transfers across the isolated boundary. The step closes when the signed scope lists in-scope and out-of-scope systems and the named owners.

2. Inventory the existing CMS estate and dependencies

   The team documents the current Cisco Meeting Server deployment, including Call Bridge, Meeting Management, databases, certificates, spaces, dial plans, and any Cisco Unified Communications Manager or video endpoint registrations. The client supplies configuration exports, licensing records, network diagrams and the list of recurring meetings. The step closes with a reviewed inventory that the client signs off, so nothing the users depend on is missed.

3. Map licensing and registration needs to the offline network

   For the current CMS, the team reviews how Smart Licensing and Meeting Management registration work when the network has no path to Cisco, and records what the client must do from inside the enclave. For Jitsi or BigBlueButton, the review confirms that no license server is needed and identifies the open-source components and their licenses. The client confirms which records and approvals its own compliance team requires. The step closes with a written licensing and registration position for each option.

4. Design the architecture and hosting baseline

   DeployOpen proposes the target design for the isolated network, covering hosts, storage, certificates from the client's internal certificate authority, DNS, media ports, firewall rules and the path by which packages and container images enter the boundary. The client confirms hardware or virtual host capacity, bandwidth and the internal naming scheme. The step closes with an approved design document and a bill of materials that the client can check against its own procurement rules.

5. Build, harden and stage the platform in a pilot

   The team installs the chosen platform in a staging area inside the enclave, applies the hardening baseline, configures authentication and recording policy, and verifies every imported package and image against its published checksums or signatures as the client's supply chain controls require. A small set of pilot users and rooms runs real meetings with the client's network and endpoint configuration. The step closes with a test record covering call quality, joining, recording, access controls and rollback.

6. Cut over meetings and retire the old service

   The team moves rooms, users and dial plans in agreed waves, keeps the existing CMS available for rollback during the window, and updates endpoint and SIP configuration. The client communicates the change to users, runs the cutover change through its own change board, and decides when the legacy service is switched off. The step closes when the client accepts the cutover checklist and the old service is disabled according to its records procedure.

7. Hand over documentation, runbooks and update procedure

   DeployOpen delivers operating documentation, configuration baselines, backup and restore runbooks, and the procedure for bringing updates into the enclave on removable media or through the client's approved transfer process. The client's administrators are trained on daily operations and incident handling. The step closes with a handover acceptance that names the internal owner for each component and records any ongoing support arrangement agreed in a separate written scope.