How to use this video conferencing requirements checklist
If you must choose or build a self-hosted meeting platform, you need one shared list of requirements before you talk to vendors or implementation partners. This checklist covers meeting sizes and concurrency, recording and streaming, end-to-end encryption, authentication and guest access, firewall and TURN needs, bandwidth, integration with a learning management system or chat, accessibility, and where media servers must sit. Each row names the decision it drives, so you can assign an owner. Security and identity teams should own authentication, guest access and encryption. Network teams should own firewall, TURN, bandwidth and media placement. Business owners, such as compliance, HR or the academic lead, should own retention, recording consent and meeting types. Platform engineering should own capacity and upgrades. Jitsi Meet and BigBlueButton are the two platforms in scope, and they differ in ways that change the answers.
Requirements should be set per meeting type, not once for the whole organization. A board call with privileged material, a clinical consultation, a timetabled classroom, and an all-staff town hall place different demands on encryption, recording, lobbies, guest access and concurrency. Write one short profile for each meeting type, listing its participants, sensitivity, peak load and recording rule. Then mark which rows apply to which profile. Where a profile cannot be met by either platform as configured, record that gap now rather than during rollout. Treat this checklist as a starting point for a written scope, not a finished specification. Each open row needs a confirmed answer from your own environment, from the vendor documentation, or from a test in a non-production setting before it becomes a requirement.
Which platform the requirements point toward: Jitsi Meet or BigBlueButton
Jitsi Meet suits ad hoc meetings of small and large size, where participants join from a link and the host needs little setup per meeting. It is licensed under Apache-2.0, and its self-hosted deployment is made of separate parts: a web server serving the app, the Prosody XMPP server, Jicofo (the conference focus) and one or more Jitsi Videobridge media routers. Because the videobridges scale horizontally, you add capacity by adding media nodes rather than rebuilding the central services.
- Authentication options: The Docker setup supports internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, all configured through the
.envfile. The handbook recommends JWT token authentication over the deprecated secure domain method. - Server layout: The official Docker setup runs separate web, prosody, jicofo, jvb, jigasi and jibri containers. Since stable-11146 the containers run rootless with read-only filesystems.
- Network needs: The Debian and Ubuntu quick start expects ports 80/TCP, 443/TCP and 10000/UDP, with 5349/TCP for TCP fallback. A proper domain certificate is needed, since the handbook warns that self-signed certificates cause problems, especially on mobile.
- Sizing: The scalable setup guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge.
Confirm with the vendor or your own tests which recording and streaming limits apply to your Jibri setup, and how LDAP group rules map to your directory.
BigBlueButton is built for virtual classrooms and sessions where the presenter needs structure. It is licensed under LGPL-3.0 and includes audio, video, slides with annotations, chat, screen sharing, polling, a multi-user whiteboard, shared notes and breakout rooms. It is embedded in learning management systems including Canvas, Moodle Cloud, Sakai, Jenzabar, D2L and Schoology. The server footprint is larger than Jitsi's, and the design choices made at install time are harder to change later.
- Server resources: BigBlueButton 4.0 requires at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth.
- Install baseline: BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit. Direct upgrades from 2.6, 2.7 or 3.0 are not supported, so a clean server is recommended.
- Network needs: TCP ports 80 and 443 and UDP ports 16384 to 32768 must be reachable, with a valid hostname for SSL and Docker for sandboxed document conversion. A TURN server is recommended for users behind restrictive firewalls.
- Identity and front end: Greenlight v3 supports external login through OpenID Connect, and the docs suggest Keycloak for Google, Microsoft or SAML login.
- API security: Every API call carries a checksum built from a shared secret, which must never be placed in a web page.
Confirm with the vendor whether your LMS integration and recording retention settings match your term calendar and policy.
In most reviews, a small set of requirements settles the choice before feature comparison starts. The first is the meeting type: unstructured calls with guests from outside the organization lean toward Jitsi, while scheduled sessions with presenters, shared whiteboards and breakout groups lean toward BigBlueButton. The second is the identity model, since JWT, LDAP and OpenID Connect routes each need a different integration owner. The third is the hosting budget, because BigBlueButton's stated minimums are higher per server, and that cost recurs for every node you run.
- Meeting pattern: Count how many meetings run at once and whether they are short calls or long timetabled sessions.
- Learning system integration: If the LMS must launch sessions, confirm the integration path your LMS supports before you pick a platform.
- Recording model: Decide where recordings land, who can delete them and how long they stay. Recording storage can dominate disk planning.
- Firewall and TURN design: Map which users sit behind restrictive networks, since both platforms need a TURN path for them.
- Upgrade rhythm: Plan upgrades around classes or meeting calendars, and check how each platform's upgrade path affects your version.
Confirm each of these answers in writing with the vendor or partner before you select a platform.
Where the media servers sit changes the design as much as the platform does. Both Jitsi and BigBlueButton need public-facing ports that clients can reach, and both need a valid certificate for the hostname users connect to. If your users are on a private network, a DMZ or behind a corporate proxy, you must plan how media traffic leaves and enters the network. Placement also determines who controls recordings and who can see logs.
- Public reachability: Jitsi needs 10000/UDP for media, and BigBlueButton needs the 16384 to 32768 UDP range. Both must reach clients directly or through a TURN relay.
- Central services: In Jitsi, the central server runs Prosody and Jicofo and can sit apart from the videobridges. In BigBlueButton, the single server carries the whole stack unless you pool servers behind a balancer.
- Scaling across sites: Jitsi scales by adding videobridges, while BigBlueButton pooling is handled by Scalelite, which you should evaluate separately.
- Certificates: Use certificates issued for your own domain, as self-signed ones cause failures for many clients.
- Logs and recordings: Keep recordings and audit logs inside the same boundary as the media servers unless policy allows otherwise.
Confirm with your network team which zones can host the media servers, and which TURN and firewall rules the vendor expects before you draft the architecture.
Functional requirements: meeting sizes, concurrency, recording and streaming
This table lists the functional requirements that size a self-hosted video platform, with the reason each one matters and how to confirm it before buying hardware. Read each row as a question to answer with your own calendar data and user base. The main takeaway is that peak concurrency and recording volume, not average use, drive most of the server and storage decisions.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Expected participants per meeting | Largest single meeting sets the minimum media capacity per room and affects whether video is shown for all participants or only active speakers. | Pull the largest invitee counts from the last 12 months of calendar data and confirm the target maximum with business owners. |
| Simultaneous meetings at peak | Concurrency, not total meeting count, determines how many videobridges (Jitsi) or BigBlueButton servers you need. | Count overlapping meetings in the busiest hour of a typical week and at known peaks such as term starts or all-hands events. |
| Recording needs | Jibri handles one recording per instance, so the number of recordings needed at once sets the recorder count for Jitsi. BigBlueButton recording needs drive disk size. | List which meeting types must be recorded, who starts recordings and how many can run in parallel at peak. |
| Streaming to larger audiences | Live streaming to viewers outside the meeting is a separate load from interactive participants and needs its own capacity test. | Define audience size and stream destinations, then run a rehearsal with the expected viewer count. |
| Retention and storage | BigBlueButton 4.0 needs 500 GB of disk for recordings (50 GB without recording) as supplied by the project install docs. Retention rules set how fast that disk fills. | Confirm retention periods with legal or records owners and calculate storage from recording length and volume per term or month. |
| Breakout rooms and whiteboards | Breakout rooms and shared whiteboards add server and client load and may not be available on every platform configuration. | Check the chosen platform's documentation for these features and test them in the pilot with realistic group sizes. |
| Screen sharing and shared documents | Screen sharing is one of the heaviest sources of bandwidth and CPU use, and it affects how many participants can view it smoothly. | Run a load test where several participants share screens at once and measure client and server behavior. |
| Mobile and browser support | Users join from many devices and browsers, and some clients need HTTPS with a valid certificate for working audio and video. | Test the browsers and mobile devices your staff and guests use, including older versions, with a valid domain certificate in place. |
| Load test and calendar-based pilot | Vendor sizing guides are starting points. A load test with synthetic meetings plus a pilot using real calendars shows actual peak behavior. | Replay anonymized calendar traffic or scripted meetings against the staging environment and record CPU, bandwidth and recording queue results. |
Security requirements: encryption, authentication and guest access
Meetings carry voice, video, chat and often personal data, so the security design has to cover how media travels, who may enter a room and what evidence proves it. The cards below cover the controls that most often decide whether a self-hosted deployment passes a security review, along with a check you can run for each one.
Transport encryption with a valid certificate
Browsers and clients need HTTPS with a certificate issued for your real domain before audio and video work reliably, and the Jitsi handbook warns that self-signed certificates cause problems, especially on mobile clients. Use an internally issued certificate on air-gapped or private networks, but confirm that every client trusts the issuing authority. To verify, load the meeting URL from a laptop, a phone and a guest network, and confirm that no certificate warning appears and that the connection is shown as encrypted.
End-to-end encryption limits
Transport encryption protects media between the client and the server, but the server can still see the stream unless end-to-end encryption is enabled. Ask whether the platform supports it for your browsers and clients, and what it disables, such as server-side recording or some features that need the server to read media. Treat it as a design decision for sensitive calls rather than a default. To verify, run a test meeting with the feature on, confirm which features are unavailable, and record that result for the risk file.
JWT authentication with a guest domain
The Jitsi handbook marks the older secure domain method, which uses username and password room creation, as deprecated for new installations and recommends JWT token authentication. Keep authenticated hosts on the secure domain and place guests on a separate anonymous domain, so that guests cannot create rooms or reach host-only features. To verify, join as an anonymous guest and try to create a room with a token-free link, then confirm the attempt is refused and that tokens expire on the schedule you set.
LDAP or OpenID Connect sign-in
Most regulated organizations need meetings to use the same directory and multi-factor policy as email and files. Jitsi Docker setups can authenticate against LDAP, and BigBlueButton Greenlight v3 supports OpenID Connect through environment variables, with Keycloak suggested as a broker for other login methods. Confirm which identity provider is authoritative, how deprovisioned users lose access to existing rooms and recordings, and whether group membership controls who can host. To verify, disable a test account in the directory and confirm it cannot join or host within your agreed window.
BigBlueButton API checksums and secret handling
Every BigBlueButton API call must carry a checksum computed from a secret shared with the server. The default is SHA-256, SHA-1 exists only for legacy integrations, and SHA-384 or SHA-512 are available since version 2.5, so ask your integrating developers which algorithm each connector uses. The shared secret must never appear in a web page, script or client-side configuration, because anyone who reads it can create or control meetings. To verify, search the rendered HTML and JavaScript of your LMS or portal pages for the secret, and confirm that checksums are generated on the server side.
Audit logging of access and changes
Record who created, joined, recorded and downloaded each meeting, and keep those logs outside the media server so an administrator cannot quietly edit them. For health and financial deployments, these logs support the audit control expectations of the HIPAA Security Rule and the retention expectations of SEC Rule 17a-4, so confirm with your compliance lead which events must be kept and for how long. Ask the implementation partner where logs are stored, how they are forwarded and how access to them is restricted. To verify, host a test meeting, then confirm each expected event appears in the central log store with a timestamp and user identifier.
Firewall, TURN and where media servers must sit
Before choosing a platform, the network team needs to know which ports must be reachable and how users behind restrictive firewalls will connect. For Jitsi Meet, the Debian and Ubuntu quick start requires 80/TCP, 443/TCP and 10000/UDP to be open, with 5349/TCP for TCP fallback and 3478/UDP for STUN as optional additions. For BigBlueButton 4.0, the install documentation requires TCP 80 and 443 and the UDP range 16384 to 32768 to be reachable, plus a valid hostname for SSL. Ask the firewall owner to confirm these rules in writing for every zone between users and the media server, including any proxy or inspection device that may alter or block UDP traffic.
A TURN server relays media for participants whose networks block direct peer connections. The BigBlueButton install documentation recommends one for users behind restrictive firewalls, and the same reasoning applies to Jitsi on guest or branch networks. Deciding whether to run TURN on your own infrastructure is a design choice with consequences for bandwidth and for where relayed media travels. Confirm whether relay traffic can be carried on TCP 443 for clients that cannot reach UDP, and whether your security team accepts an internal TURN service for staff and external guests.
Where the media servers sit determines latency, legal exposure and who can reach the service. Users inside a regulated network may need the video bridge or BigBlueButton server inside that network, while guests and patients on the public internet need a controlled entry point, usually a reverse proxy or DMZ. Each placement affects which region the media path crosses and whether recordings leave the enclave. Treat the region and network path as a decision to confirm with the network and compliance teams, not as a default inherited from a hosting provider. Document the chosen path before procurement, because changing it later usually means re-testing firewall rules, certificates and TURN configuration.
Integration requirements: LMS, chat, identity and calendars
A video platform rarely works alone. Meetings start from a learning management system, a chat channel, a directory or a calendar, and each of those connections sets requirements the platform must meet before rollout. The cards below name the connection points and the questions to settle with the owner of each integrating system.
LMS embedding for classrooms
BigBlueButton is embedded in Canvas, Moodle Cloud, Sakai, Jenzabar, D2L and Schoology, which the project says represent over 75% of the worldwide LMS market. Confirm with the LMS administrator which embedding method your LMS supports, whether LTI launch is available, and which role mapping (instructor, moderator, student) the course roster will pass through. Confirm that your LMS version is on the project's supported list before committing to a design.
Chat and workspace links
Meeting links posted into team chat or a project tool need a stable room address, a predictable join method and clear rules for who can open the room. Agree with the chat or workspace owner whether links open a lobby, require sign-in, or accept guests. Test link previews and deep links with each client you support, since a link that works in a browser may not open cleanly in a mobile app.
Identity through OpenID Connect and Keycloak
Greenlight v3 supports external authentication through OpenID Connect, configured with environment variables, and the project's documentation suggests Keycloak to add Google, Microsoft, SAML and other login methods. Confirm with the identity team which realm, client and claim mapping will be used, and who controls group membership that decides moderator rights. Plan for session expiry and account deprovisioning so removed staff cannot keep joining rooms.
Greenlight or LTI on the same server
The bbb-install.sh script can install BigBlueButton together with the Greenlight front end or LTI support on one server. This keeps the first deployment simple, but it places the web front end, the media stack and any recording storage on the same host. Ask the platform owner whether that co-location is acceptable for your user count, and whether the LTI and Greenlight components will be upgraded on the same schedule as the core server.
Calendar invitations
Scheduled meetings reach attendees through calendar invitations, so the team must decide who creates the invite, where the join link comes from, and how a changed room or time propagates. Confirm with the mail or groupware owner which calendar system sends invitations, whether the invite can carry a dial-in or lobby note, and how external guests receive links without a directory account. Test the invite flow on the mail clients your staff actually use.
API checksum and secret handling
Every BigBlueButton API call must carry a checksum computed with a secret shared with the server, and the documentation warns against embedding that secret in a web page. Any custom integration, whether a scheduling tool or a portal, must compute checksums on a back end that holds the secret. Confirm with the integrating developer which checksum algorithm the server accepts and how the secret is rotated when someone with access leaves the project.
Operational requirements and how to verify them
This table lists the operational requirements that decide whether a self-hosted meeting platform stays reliable after launch, with a check the reader can run for each one. Read it as a set of questions to put to a vendor, a partner or your own platform team before signing off the design. The main takeaway is that hardware minimums, upgrade paths and peak runbooks are easy to underestimate and are cheap to verify early.
| Requirement | What it asks for | How to verify |
|---|---|---|
| Hosting resources for BigBlueButton | BigBlueButton 4.0 needs at least 16 GB RAM with swap, 8 CPU cores with high single-thread performance, 500 GB disk for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth | Compare the proposed server specification against these minimums in the BigBlueButton install docs and ask for the measured load per concurrent meeting |
| Central server and videobridge sizing for Jitsi | Jitsi's scalable guidance suggests 4 CPU and 8 GB for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge | Ask the implementer to show the sizing per bridge and the expected meetings per bridge, then load test with realistic participant counts |
| Horizontal scaling of videobridges | Jitsi videobridges scale by adding more instances, and the default install is already configured for horizontal scaling | Confirm the bridges register with the central components after adding one, and run a test where new meetings land on the new bridge |
| Capacity for classroom and meeting peaks | Timetabled starts or all-hands calls create simultaneous load that average use does not show | Ask for a written runbook that names peak windows, pre-warm steps, the trigger for adding a server, and who makes that call |
| Upgrade path | BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so a clean server installation is the documented route | Confirm the current version on each server, and ask the partner for a migration plan that includes recordings, users and LMS connections |
| Patching cadence and maintenance windows | Releases arrive across several branches, including maintenance releases on older branches, so patching needs a fixed schedule | Ask who tracks releases, how fast security updates are applied, and how maintenance windows avoid scheduled classes and meetings |
| Rootless containers in Jitsi Docker | Since stable-11146, Jitsi Docker containers run rootless with read-only filesystems | Check the running containers for their user, confirm the read-only filesystem setting, and review any volume mounts that need write access |
| Backups and restore testing | Databases, configuration, recordings and secrets each need a backup scope and a tested restore | Ask for the backup scope per component, the retention period agreed in writing, and a restore test result from a clean host |
| Monitoring and alerting | Operators need signals for CPU, memory, bandwidth, failed joins and recording jobs before users report problems | Confirm which metrics, thresholds and alert recipients are defined, and that a test alert reaches the on-call person |
Questions buyers ask before choosing a platform or partner
How much effort does a video conferencing requirements exercise take, and who needs to be in the room?
The effort depends on how many meeting types you must support, how many policies apply and how many teams own a decision. Plan for the platform owner, a network engineer who knows your firewall and DNS, an identity owner for login and guest access, and a records or legal owner for recording and retention. Sizing questions also need someone who can state peak concurrency from real calendars, class timetables or event schedules. Ask any partner to list the workshop inputs they need from you in writing before they quote, because missing inputs are the most common reason a scope grows after signing.
How long do a requirements workshop and a pilot take?
The honest answer is that the duration depends on the number of stakeholders, the number of meeting types and how quickly your owners can decide on recording, guest access and retention. We do not publish durations for these steps. Ask for the workshop agenda, the decisions each session should close and the pilot exit criteria, such as a tested join path from outside the corporate network and a confirmed recording location. A fixed-scope plan should state these milestones and their dependencies in writing before work starts.
What does the work need from our network, identity, legal and records teams?
Each owner has a concrete input. The network team must confirm which ports can be opened to the internet, and BigBlueButton's install documentation lists TCP 80 and 443 and UDP 16384 to 32768, while Jitsi's Debian and Ubuntu quick start lists 80/TCP, 443/TCP and 10000/UDP. The identity team decides between internal accounts, JWT tokens, LDAP or OpenID Connect, and must confirm which identity provider holds the users. Legal and records owners define how long recordings are kept, who may access them and how deletion works. Ask a partner to name these owners and the decision each one must sign off on.
Can our internal team run Jitsi or BigBlueButton without a partner?
A capable platform team can run either project, but the question is whether it has capacity for the work and the ongoing operations. Both projects publish installation and scaling documentation, so the steps are documented. The harder parts are TLS certificates that browsers trust, TURN coverage for users behind restrictive firewalls, recording storage, upgrades that do not interrupt scheduled classes or meetings, and load testing before a peak. Self-assess against those items. If several are new to your team, a partner can plan, implement and document the work, then hand over runbooks.
What drives server and bandwidth cost up or down?
Cost follows peak concurrency, not average use. Your largest cost drivers are the number of simultaneous meetings or classes, the share of participants sending video, whether recording or streaming runs and how long recordings are retained. Hardware and bandwidth are one-time and recurring costs, while operations and upgrades recur. The BigBlueButton 4.0 install documentation lists a single-server baseline of at least 16 GB of RAM, 8 CPU cores, 500 GB of disk with recording (50 GB without) and 250 Mbit/s symmetrical bandwidth. For Jitsi, the scalable setup guide suggests a 4 CPU, 8 GB central server and 4 or 8 CPU with 8 GB RAM per videobridge. Ask any quote to show the concurrency assumption, the recording retention period and the bandwidth per meeting.
Can a partner turn these requirements into a fixed-scope plan?
Yes, that is the usual shape of an engagement. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support and upgrades are available as retainers. A plan built from this checklist should list each requirement, the decision that closes it, the acceptance test and the owner. DeployOpen does not publish a price list, so the written scope is what produces a quote.
Should we choose Jitsi or BigBlueButton for our requirements?
Choose based on the meeting type rather than on feature lists alone. Jitsi Meet is licensed under Apache-2.0 and is built from a web server, Prosody, Jicofo and Jitsi Videobridge, which scale by adding bridges. BigBlueButton is licensed under LGPL-3.0 and is oriented to virtual classrooms, with polling, shared notes, breakout rooms and LMS embedding. Jitsi fits ad hoc meetings and customizable authentication, while BigBlueButton fits timetabled teaching and LMS-centered use. Confirm whether either supports your recording, encryption and accessibility needs in your own test before you decide.
Which compliance evidence a meeting platform can support
Compliance evidence for a meeting platform comes from decisions you make about recordings, chat artifacts, transport and logs, so map those decisions to the rules before you choose a design. Two US rules are the usual starting points. SEC Rule 17a-4(b)(4) requires broker-dealers to preserve originals of communications received and copies of communications sent relating to the business, for not less than three years, and the question for a meeting platform is whether a recording, a transcript or in-meeting chat counts as such a communication under your own retention policy. HIPAA's Security Rule at 45 CFR 164.312(e)(1) requires technical measures that guard against unauthorized access to ePHI sent over a network, and 164.312(b) requires audit controls that record and examine activity in systems containing ePHI. Confirm with counsel which of these, if any, applies to your meetings before you design for them.
Once applicability is settled, identify the evidence each control needs and where it will come from. For transmission security, that means documented TLS configuration on the web entry point, a certificate from your own trusted authority or a public CA, and proof that unencrypted media ports are closed to the internet. For audit controls, ask which events the platform logs (room creation, authentication outcomes, moderator actions, recording start and stop) and whether those logs leave the media server for a central store with retention you can set. In Jitsi, authentication is configured through the .env file and JWT settings, and in BigBlueButton, API calls are protected by a checksum made with a shared secret, so evidence of those settings belongs in your change records. Confirm the exact log fields with each vendor or project, since this page does not assume them.
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration baselines, retention settings, access records and runbooks. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make those determinations. Before scoping an implementation, ask your counsel to confirm which retention periods and safeguards apply to recordings and chat artifacts, and ask your auditor which evidence they will accept. A written scope that names the retention store, the log destination, the certificate source and the access review process will make the assessment far less painful than assembling those facts afterward.
How to verify the requirements before you commit
This sequence turns the requirements in this checklist into tested facts about your users, network and load before you choose a platform or sign a scope. Each step produces a written artifact that a named owner approves, so the final decision rests on evidence rather than vendor claims.
Write requirements for each meeting type
Split your meetings into types such as board calls, client advisory calls, all-hands sessions and external guest sessions, and record the expected participant count, peak concurrency, recording needs, guest access and encryption expectations for each. Business owners and the compliance lead should sign the document, and it is done when every meeting type has a stated maximum size and a named owner for its recordings.
Confirm ports and TURN with the network team
Ask the network team to confirm which inbound and outbound ports are open at the perimeter, including the TCP and UDP ranges that Jitsi and BigBlueButton require, and whether a TURN service is needed for users on restrictive networks. The check is complete when the team signs a port matrix that matches the install documentation for the chosen platform, and any gaps are logged as tickets.
Pilot with real users behind their firewalls
Run a short pilot with staff, guests and external participants on the networks they actually use, including home connections, branch offices and any partner networks that filter traffic. Record which users could not join, audio or video failures and the connection path used, then review the results with the network team. The pilot is done when every meeting type has been tested from each network category you plan to support.
Run a load test at expected peak concurrency
Simulate the highest number of simultaneous meetings and participants from your requirements, using the sizing guidance from the platform vendor as the starting point, and measure CPU, memory, bandwidth and media quality while the load runs. The test is complete when the results show the peak target is met with headroom, and the operations lead accepts the scaling plan for growth beyond that peak.
Review security and identity settings
Check how authentication is configured for hosts and guests, whether HTTPS uses a certificate trusted by all client devices, how recording storage and access are protected, and whether end-to-end encryption is required for any meeting type. The security lead should verify each setting against the written requirements, and the review is done when every gap has an accepted risk or a remediation ticket.
Sign off with named owners
Gather written approval from the business owner, network team, security lead, compliance lead and operations lead, covering the requirements, pilot results, load test results and open risks. The sign-off is complete when each owner has approved in writing, and any open items have an assigned owner and a target date before the scope is agreed with an implementation partner.
Questions that separate platforms and partners
Ask every partner how they size capacity before they quote hardware. For Jitsi, the question is how many videobridges they will run, how they measured concurrent participants per bridge, and whether the central server is sized separately. The Jitsi scalable setup guide describes videobridges that scale horizontally by adding more, with a suggested 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each bridge. For BigBlueButton, the question is which server sizes they use and how they pool servers when timetabled peaks overlap. Ask for the sizing worksheet, not a single headcount figure. The BigBlueButton 4.0 install docs list 16 GB RAM with swap, 8 high single-thread CPU cores, 250 Mbit/s symmetrical bandwidth and 500 GB of disk for recordings, so ask the partner to show how each figure changes with their peak load.
Ask how recording storage grows and who owns it. Recordings usually drive more disk growth than live media, so ask how many hours a term or month they expect, where files land, how long they are kept, and how deletion works. Confirm whether the BigBlueButton disk figure includes recording retention. Ask how users behind restrictive firewalls connect: which of the required ports they open (TCP 80 and 443, UDP 16384 to 32768 for BigBlueButton, UDP 10000 and TCP 443 or 4443 for Jitsi), whether they deploy a TURN server, and how they test it from the networks your users actually use. Authentication deserves the same scrutiny. Jitsi's handbook marks the older secure domain method as deprecated and recommends JWT tokens with a separate anonymous domain for guests, so ask which method they will configure and how guest access is kept apart from staff accounts. For BigBlueButton, ask how Greenlight is connected to your identity provider through OpenID Connect and who manages the shared secret used for API checksums.
Finally, ask how load balancing and upgrades will be handled. For BigBlueButton, ask whether they plan to pool servers behind Scalelite and how it routes new meetings. For Jitsi, ask how bridges are added or drained without dropping live meetings. Ask for a written upgrade calendar that avoids class times and scheduled town halls, and a rollback plan. Note that BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so ask whether a clean install and migration is in scope and who performs it. Ask every partner for a written statement of what they will test before go-live, what they will not test, and what evidence they will hand over. The video conferencing RFP questions hub lists the full set of questions to put to each bidder.
How DeployOpen scopes, delivers and supports video conferencing implementations
DeployOpen turns a video conferencing requirements checklist into a written scope, then plans, implements, hardens, documents and hands over a self-hosted Jitsi Meet or BigBlueButton deployment inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Confirm peak concurrent meetings, participant sizes and whether recording or streaming is required before any design work starts.
- Record which identity sources, guest access rules, firewall limits and TURN needs apply in your network and hosting location.
- Agree deliverables, timelines and responsibilities in writing so the quote follows directly from the defined scope.
How we build
- Map each checklist item to a component: web server, Prosody, Jicofo and Jitsi Videobridge, or BigBlueButton server with its recording storage.
- Configure authentication, such as JWT tokens or LDAP for Jitsi, or OpenID Connect for Greenlight, and test guest access paths.
- Validate firewall rules, TLS certificates and TURN reachability from the networks your users actually connect from.
How we hand over
- Document the architecture, port map, sizing assumptions, configuration keys and the upgrade procedure for your operations team.
- Provide evidence for compliance assessments, such as configuration records and access logs, without issuing any audit opinion.
- Run a handover session that walks your administrators through monitoring, backups and recording deletion before go-live.
How we support
- Offer ongoing support, upgrades and continuous testing through a retainer that follows the scope agreed at handover.
- Plan upgrades around your meeting or class calendar, and confirm the release path for each platform version before applying it.
- Review capacity and security findings periodically, and extend the scope in writing when new meeting types or integrations are added.
