Which fits your on-premises video: Cisco Meeting Server or Jitsi Meet
Cisco Meeting Server fits best when your on-premises video is already tied to Cisco Unified Communications Manager, SIP room systems and endpoints, and Cisco support contracts that your procurement and operations teams know how to manage. Its Call Bridge and Meeting Management components sit inside an estate that many organizations have already standardized on, and the licensing model through PMP Plus and SMP Plus host licenses is part of that relationship. Jitsi Meet fits when you want web-based meetings that any participant can join from a browser, no per-host license fees, and an operating model your own platform or infrastructure team can run. Jitsi Meet is Apache 2.0 licensed and is built from a web front end, Prosody, Jicofo and Jitsi Videobridge, so the software cost is zero but the work of running those services is yours.
The decision turns on three things. The first is SIP and endpoint dependencies: list every room system, video endpoint and CUCM trunk that calls into your current spaces today, then confirm which of them need SIP dial-in and whether Jigasi, the SIP gateway in Jitsi, covers those flows for your dial plan. If endpoints are deeply registered to CUCM, replacing the bridge is a bigger change than replacing the meeting service. The second is in-house operating skill: Jitsi requires HTTPS with a proper domain certificate for working audio and video, and scaling means adding videobridges, so you need people who can own certificates, networking and capacity. The third is the support model: CMS comes with vendor support, while Jitsi support comes from your own team, from DeployOpen or another implementation partner, or from the hosted option offered by 8x8, which is a different trade-off. Ask each vendor for written terms before you commit, and confirm current release dates and support windows with them directly.
Which option fits which scenario
This table maps common Cisco Meeting Server scenarios to the better fit between self-hosted Jitsi Meet and the Meeting Server, with the reason tied to Jitsi's component model. Read each row against your own environment: a true value in the Jitsi column means the scenario fits Jitsi's design, not that Cisco cannot serve it.
| Scenario | Better fit | Reason |
|---|---|---|
| Room systems registered to CUCM | Cisco Meeting Server | Jitsi has no CUCM registration path; keep CMS if endpoints depend on existing SIP and CUCM call control, and confirm any SIP gateway work with Jigasi first. |
| Browser-first meetings for staff and guests | Jitsi Meet | Participants join from a browser link, and Jitsi's web front end, Prosody, Jicofo and Videobridge serve that flow without per-seat client software. |
| SIP dial-in from outside the browser | Cisco Meeting Server | Jitsi offers SIP through the optional Jigasi gateway; confirm the dial-in patterns, numbering and call features you need before assuming parity. |
| Public-facing meeting links | Jitsi Meet | Jitsi requires HTTPS with a proper domain certificate, so a published domain with a valid certificate is part of the design rather than an extra. |
| Air-gapped or disconnected networks | Jitsi Meet | Jitsi runs on your own Debian or Ubuntu hosts or containers with no license server; updates must be staged into the enclave, so plan the transfer process. |
| Recording and streaming needs | Jitsi Meet | Recording and streaming run through the optional Jibri component, which you deploy and size separately; confirm output formats with your compliance team. |
| Small operations team | Cisco Meeting Server | Jitsi has several components to patch and monitor, and Cisco's vendor support model may be easier for a small team; weigh staff time against licence cost. |
How a self-hosted Jitsi stack is assembled
A self-hosted Jitsi deployment is not one server but a set of cooperating services, and the reader's first task is to map each one to a role. The web front end (nginx or Apache, serving the Jitsi Meet web app) is what participants load in a browser. Prosody, the XMPP server, handles signaling and account state, and Jicofo, the conference focus, creates conferences and decides which videobridge each participant joins. The media itself flows through one or more Jitsi Videobridge (JVB) instances, which are the media routers. Optional components sit beside them: Jibri records and streams meetings, and Jigasi acts as the SIP gateway that lets room participants be reached from telephone or SIP endpoints. Where Cisco Meeting Server uses Call Bridge and Meeting Management, the Jitsi equivalent is spread across these services, so ask your integrator to show you which host runs which role before you size anything.
The packaging choice affects how that layout is operated. The official Docker setup runs web, prosody, jicofo, jvb, jigasi and jibri as separate containers configured through a .env file, while the Debian and Ubuntu packages install the same roles directly on hosts. Both are supported, so the decision should rest on your team's container and configuration management practices rather than on any difference in function. Whichever you choose, confirm the supported operating system versions in the Jitsi self-hosting guide and check that the HTTPS certificate plan is settled early, because the handbook treats it as necessary for audio and video to work.
Capacity is where the layout pays off. The scalable setup guide describes adding videobridges horizontally, and the default install is already configured for that, so media load can be spread across additional JVB hosts while the central services stay in place. Before committing, ask for the sizing the integrator expects for your concurrent meeting profile, the number of bridges you will start with, and how a bridge is added and drained during maintenance. Also confirm how recording and SIP capacity scale, since Jibri and Jigasi are sized separately from the videobridges and carry their own host requirements.
Where the data lives and who controls the platform
Cisco Meeting Server and self-hosted Jitsi Meet both can keep media on your premises, but they differ in who holds the licenses, the hosts, the identity layer and the certificates. The cards below cover the decisions that determine data location and control, and the evidence you will need to show an assessor.
Data location in each model
Cisco Meeting Server keeps call media on the servers you deploy, but licensing and Cisco-managed components still need a route to Cisco's services. Self-hosted Jitsi Meet has no vendor service in the media path, so meetings, chat and recordings stay where you install the Jitsi containers or packages. Confirm where Jibri recordings are written and how long they are kept, because the storage location is set by your own configuration.
Hosting on Cisco hardware or VMware
Meeting Server runs on Cisco hardware or on VMware, so the hypervisor, host firmware and Cisco-supported platform rules shape your patching window and hardware refresh. Jitsi runs on any Linux host you control, including bare metal, VMware, Proxmox or a public cloud account in your name. Check whether your data center or air-gapped enclave can support the host profiles you choose, and who owns the hypervisor patch cycle.
Identity options for room access
Jitsi's Docker guide lists internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, all configured through the .env file. The handbook marks the older secure domain method as deprecated for new installs and recommends JWT with a separate anonymous domain for guests. Map each option to your directory, decide who can create rooms, and test guest access separately before go-live.
HTTPS and certificate ownership
Jitsi's handbook states that HTTPS is necessary for multimedia to work, and that self-signed certificates cause problems, especially with mobile clients. You therefore need a certificate for your domain from a CA you choose, with renewal assigned to a named team. Cisco Meeting Server certificate handling should be compared in your own environment, including which endpoints trust your internal CA and who rotates the keys.
Compliance evidence and assessor support
Both models produce evidence an assessor will ask for: access logs, change records, patch history, configuration baselines and backup tests. DeployOpen prepares the systems, controls and evidence for a compliance assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so agree with them early which artifacts they need from each platform.
Operating effort: what your team runs day to day
An in-house team owns every layer of a self-hosted Jitsi deployment: the web front end, Prosody, Jicofo, the Jitsi Videobridge instances and any optional Jigasi or Jibri components. Nothing in the stack is licensed per seat or per node, so the cost of running it is mostly staff time, infrastructure and the skills to operate it. Ask whether your team already runs Linux servers, reverse proxies, Docker or Debian and Ubuntu packages, and how many people can be on call for media problems during a live meeting.
- Skills and coverage: Confirm that at least two people can troubleshoot XMPP, bridge media paths and TLS issues, because a single operator becomes a single point of failure.
- Release handling: Plan a recurring process to track stable Jitsi Meet builds, read release notes and test them before rollout.
- Runbooks: Write procedures for restarting a videobridge, draining a node and rotating a failed component.
- Monitoring: Decide which signals you collect, such as bridge load, active conference counts and certificate expiry, and who is alerted.
- Training budget: Include time for staff to learn the stack, which is a one-time cost that recurs when people leave.
Before committing, ask your team to estimate its own weekly hours for patching, monitoring and incident response, and compare that with the support scope you already pay for on Meeting Server.
A partner-supported model keeps internal staff focused on use and integration while an outside team handles routine operations under a written scope. DeployOpen works this way for some clients: it plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside the client's own infrastructure, and ongoing support, upgrades and continuous testing are available as retainers. Fees depend on the agreed scope, so ask for a quote built from the tasks listed below.
- Defined responsibilities: Agree in writing who applies upgrades, who watches alerts and who responds at night.
- Response expectations: Ask for the stated response times and escalation path, and confirm whether they are written as service levels in the contract.
- Upgrade cadence: Specify how often builds are tested and promoted, and whether the partner tests on a staging environment first.
- Knowledge transfer: Require documentation and runbooks so the platform can move back in-house if the relationship ends.
- Access and evidence: Confirm how partner staff access your servers, how sessions are logged and where operational records are kept.
A retainer converts irregular internal effort into a predictable recurring cost, but it does not remove the need for someone on your side who understands the business impact of an outage.
Jitsi Meet publishes stable releases tagged by build number, for example stable/jitsi-meet_11248, so an upgrade plan should reference build numbers instead of informal version names. The jitsi-meet repository on GitHub is the primary place to see new tags and their changes. Docker deployments are updated by pulling new images and restarting containers, while Debian and Ubuntu packages are upgraded through the normal package manager. Test each build against your authentication setup, since JWT, LDAP and Matrix options configured in the .env file can change behavior between releases.
- Build tracking: Subscribe to repository releases and record the build number running in each environment.
- Staging first: Keep a staging deployment that mirrors production domain, certificates and authentication.
- Rollback path: Keep the previous image or package version available so a failed upgrade can be reverted.
- Dependency checks: Confirm the Java runtime and operating system versions required by the build, since the Debian and Ubuntu quick start sets minimum OS releases and OpenJDK 17.
- Change windows: Schedule upgrades outside meeting peaks and announce them to users.
Ask your team to show the last three upgrades it performed on a comparable stack, with the test steps and rollback decisions recorded.
Two recurring tasks cause most unplanned Jitsi outages: failed HTTPS certificate renewal and resource exhaustion on media servers. Jitsi's handbook says HTTPS with a proper domain certificate is necessary for audio and video to work, and it warns that self-signed certificates cause problems, especially with mobile clients. Renewal therefore has to be automated and tested, not handled as a yearly calendar item. Monitoring should cover the web endpoint, the certificate expiry date, the videobridge health and the TCP and UDP ports the platform depends on.
- Automated renewal: Configure the certificate client to renew before expiry and alert if the renewal fails.
- Expiry alerts: Raise warnings well before the certificate lapses, and check the chain after each renewal.
- Media ports: Monitor 10000/UDP and the TCP fallback port, because a blocked port degrades calls without a visible web error.
- Bridge metrics: Track CPU, memory and active conference counts on each videobridge.
- Log retention: Decide how long logs are kept and where they are stored, and confirm that this meets your internal policy.
Ask your team to test an expired or revoked certificate in staging and confirm which alerts fire and who receives them.
Jitsi's scalable setup guide says videobridges scale horizontally by adding more, and that the default install is already configured for horizontal scaling. It suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. These are starting points from the vendor documentation, not guarantees for your traffic. Meeting Server capacity was planned around its own node profiles, so your existing sizing data will not transfer directly. Real capacity depends on participant counts, video quality settings, screen sharing, network paths and whether recording is active.
- Load testing: Run synthetic meetings at your expected peak with realistic participant counts and video settings before go-live.
- Growth headroom: Measure how many concurrent participants one bridge sustains, then add bridges for the peak plus a failover margin.
- Bandwidth: Confirm upstream and downstream capacity at each site, since media traffic scales with participants.
- Recording load: Plan separately for Jibri if recording or streaming is required, because it adds resource demand.
- Review cycle: Repeat tests after each major upgrade and after meeting volume changes.
Use the suggested machine sizes as a starting configuration, and ask any partner or internal team to present load test results before accepting capacity commitments.
What a move from Cisco Meeting Server to Jitsi Meet involves
The sequence turns Meeting Server spaces, dial-in numbers and endpoint registrations into a tested Jitsi deployment that users can join without a cutover surprise. Each step ends with a written output the project team can check before moving on.
Inventory spaces, users and SIP dependencies
The project owner exports the list of Meeting Server spaces, their owners, access rules, dial-in numbers and recording settings, and records which of them are reached from CUCM, VCS-era trunks or other SIP gateways. Someone from the telephony team confirms every SIP route that lands on the Meeting Server. The output is a register of spaces and call paths, with each one marked as keep, recreate or retire.
Size bridges and build a staging environment
The platform team reads the Jitsi scalable setup guide, which describes one central server and one or more videobridges that scale by adding machines, and works out how many bridges the peak meeting load needs. They build a staging copy with the Docker or Debian and Ubuntu install path and load it with test meetings. The output is a sizing note tied to measured load in staging, not to the Meeting Server's licensed capacity.
Choose the authentication model
The security lead decides how meeting access is controlled, choosing between JWT tokens, LDAP, internal XMPP accounts or the Matrix-based options the Docker guide lists, and confirms that the deprecated secure domain method will not be used for new installs. Guest access goes on a separate anonymous domain. The output is a signed decision record that names the identity source and who can create rooms.
Recreate spaces as persistent room names
Meeting Server spaces have no direct equivalent, so the team maps each one to a named Jitsi room, with naming rules that keep room names hard to guess and tied to an owner. Where a JWT model is used, the application that issues tokens defines which users may enter which rooms. The output is a room catalog with owners and access rules, checked by a test user from each group.
Rebuild SIP dial-in through Jigasi
Dial-in users and SIP endpoints that reached Meeting Server spaces are connected through Jigasi, the SIP gateway in the Jitsi stack. The telephony team confirms the SIP trunk or gateway settings, the dial-in numbers and the PIN or room mapping, and tests call setup and audio quality with real endpoints in staging. The output is a signed-off test log for each dial-in path. Confirm with your SIP provider and your Jigasi version which codecs and call features your endpoints need.
Plan the endpoint and CUCM changes
Video endpoints registered to CUCM and calling into Meeting Server spaces need a changed dial target or a changed call route, and the voice team decides which devices move in the first wave. Browser and app users simply receive a new room link. The team checks how each endpoint model handles the Jitsi dial path before the cutover date is set. The output is a per-device change list with owners, reviewed by the voice team.
Run both platforms in parallel
Users keep the Meeting Server for scheduled meetings while a pilot group uses Jitsi for new meetings, with feedback collected on join experience, audio, screen sharing and dial-in. The team monitors bridge load and HTTPS certificate health during this period, since the Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video. The output is a pilot report that lists open defects and the criteria for moving the remaining users.
Cut over and retire Meeting Server routes
The project owner moves the remaining users, redirects the dial-in numbers and endpoint routes, and announces the new room links. The Meeting Server is kept as a fallback until the agreed exit criteria are met, then licenses, certificates and routes are released. The output is a closed cutover record with the retirement date signed by the service owner.
Questions buyers ask before choosing
How much does it cost to move from Cisco Meeting Server to Jitsi Meet?
Jitsi Meet carries no license fee because it is licensed under Apache 2.0, so the cost sits in infrastructure, implementation and operations. The one-time costs are design, deployment, authentication and SIP integration, testing and endpoint changes. The recurring costs are servers, bandwidth, patching, monitoring and any support contract you buy. On the Cisco side, the cost of PMP Plus and SMP Plus licenses, Meeting Management and support depends on your agreement, so confirm those figures with Cisco or your reseller and note when each renews. Ask for an itemized quote built from a written scope, and check how participant count, number of videobridges and recording needs change the total.
How long does a Jitsi Meet deployment take to stand up?
The timeline is set by the written scope, not by the product alone. A single-server install on a supported Linux host follows the official quick start, but a production rollout also needs a public domain, a valid certificate, authentication, videobridge capacity, SIP dial-in if required, and testing with your real endpoints and clients. Each of those adds work and approvals. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for a dated plan that lists each of these items separately. Confirm with your own change board how long certificate issuance and firewall changes take, because those often control the schedule.
What does our own team need to provide for a Jitsi rollout?
Your team supplies the environment and the approvals, and the implementation work builds on them. Expect to provide:
- A public DNS name for the meeting domain and a certificate that browsers trust
- Firewall rules for 80/TCP, 443/TCP and 10000/UDP, plus 5349/TCP and 3478/UDP if you use TCP fallback and STUN
- An identity source for authentication, such as LDAP, JWT tokens or Matrix verification
- Linux and Docker administrators for hosts and containers
- Network staff for NAT and the public addresses of the videobridges
- The SIP and telephony owners, if dial-in is in scope
- A named owner for recording storage, retention and access
Agree these responsibilities in the written scope so that delays do not fall on the implementation schedule.
Can our own staff deploy Jitsi Meet without outside help?
Yes, a team with Linux, Docker, networking and TLS skills can install Jitsi Meet from the official documentation, which covers both Debian and Ubuntu packages and Docker containers. The harder work is what comes after the first meeting works: authentication integration, sizing and scaling videobridges, hardening, backup, upgrades and documenting the setup for auditors. Ask whether your team can staff those tasks for the life of the platform. DeployOpen plans, implements, customizes, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure under fixed-scope agreements, and offers ongoing support as a retainer, so you can choose to hand over the whole project, part of it, or only the operations.
Can Jitsi Meet replace SIP room systems and Cisco video endpoints?
Jitsi Meet can accept SIP dial-in through Jigasi, the SIP gateway in the official deployment, so audio callers can join meetings. It is a web conferencing platform, though, and whether it matches the call control, endpoint registration and room system behavior you rely on today is a question to test rather than assume. Make a written list of the endpoint types, call flows and CUCM integrations in use, then run each one in a lab against the Jigasi configuration. Confirm with your vendors which features Cisco endpoints depend on before you plan the cutover, because some may need a different design or remain on the existing system.
Does HTTPS and certificate setup delay a Jitsi rollout?
It can, because the Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video. The same guidance warns that self-signed certificates cause problems, especially with mobile clients. Start the certificate work early: confirm the public or internal name, the issuing authority, and how renewals will run. For air-gapped or internal networks, check that your internal certificate authority is trusted on every managed browser and device that will join meetings. Test on mobile clients as well as desktops, since a certificate that works in a browser may still fail on a phone.
What support is available for Jitsi compared with Cisco Meeting Server?
Jitsi Meet is open source, so its documentation, GitHub repository and community are free to use, and 8x8 offers Jitsi as a Service as a hosted option, which is a different service from running your own servers. Cisco support is delivered under your Cisco contract, so confirm its coverage, hours, response targets and escalation path in writing before you compare it with other options. For a self-hosted Jitsi estate, support usually means a retainer covering upgrades, monitoring, incident response and continuous testing. DeployOpen offers ongoing support, upgrades and retainers. Ask any provider for the response times, scope of coverage and handover documents in the contract.
How many videobridges and how much server capacity does Jitsi need?
The Jitsi scalable setup guide suggests a central server with 4 CPU and 8 GB of memory, and a videobridge with 4 or 8 CPU and 8 GB of memory, and it notes that the default install is already set up for horizontal scaling. Treat these as starting points from the vendor guide, not as a sizing result. Actual capacity depends on concurrent participants, video quality, screen sharing and the bandwidth at each site. Ask for a load test against your peak meeting profile before go-live, and plan to add videobridges as you grow, since the design expects you to scale out.
Official sources to read next
Start with the Jitsi self-hosting guide in the Jitsi handbook. It sets out the components a deployment needs: the web front end, Prosody, Jicofo and Jitsi Videobridge, with Jibri and Jigasi as optional add-ons. Read it against your current Meeting Server design, and note which roles (Call Bridge, Meeting Management, the SIP edge) have no one-to-one equivalent. Those gaps decide how much of the SIP and room-system work stays in your own design, so confirm them before any sizing discussion with a partner.
Next, read the Docker guide if your platform team runs containers, and the scalable setup guide if you expect load to grow. The Docker guide covers the .env file, where authentication options such as JWT, LDAP and internal XMPP accounts are configured, and it notes that the containers run rootless with read-only filesystems. The scalable guide explains that videobridges scale horizontally by adding more of them. Use both to test whether your authentication model and capacity assumptions hold before you commit to a design.
Finally, review the Jitsi security and privacy page with your security and compliance leads. Ask the same questions you would ask of any product in a Meeting Server review: how the platform handles encryption, what data it stores and where, and how vulnerabilities are reported and fixed. Record the answers and the version you tested against. Treat vendor statements as the starting point for your own evidence, and have your independent assessor or auditor decide what satisfies your controls.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move from Cisco Meeting Server to Jitsi Meet stays under your control. Work starts with a written scope that covers your Call Bridge, Meeting Management and SIP environment before any build begins.
How we scope
- Inventory of current CMS spaces, call flows, SIP trunks and CUCM-registered endpoints that must keep working
- Written decision on which meeting features move to Jitsi and which stay on Cisco
- Agreed deliverables and timelines in writing before any work starts, as engagements are fixed-scope
- Quote built from the written scope, since DeployOpen publishes no price list
How we build
- Jitsi deployment in your own cloud accounts, data centers or air-gapped network, using the supported Docker or Debian and Ubuntu paths
- HTTPS with a proper domain certificate, plus JWT token authentication with a separate anonymous domain for guests
- Videobridge sizing and horizontal scaling plan, with optional Jigasi for SIP dial-in tested against your gateways
- Security testing of the deployed platform before go-live, where the scope includes it
How we hand over
- Runbooks for installation, configuration keys, upgrades, backups and recovery, written for your operations team
- Documented controls and evidence that your own auditors can review, noting that DeployOpen prepares evidence but does not issue audit reports or certifications
- Knowledge transfer sessions with your engineers, with the scope defining their length and attendees
- Final acceptance against the criteria agreed in the written scope
How we support
- Ongoing support, upgrades and continuous testing available as a retainer once handover is complete
- Upgrade planning for each Jitsi release, with testing in a staging environment before production changes
- Clear confirmation of which costs you pay for, including your own servers, bandwidth and internal operations time
- Support scope and response expectations agreed in writing as part of the retainer
