Video conferencing RFP questions for vendors

Video conferencing RFP questions to ask before you hire a partner

If you must choose a partner to run Jitsi Meet or BigBlueButton inside your own network, this page gives the questions to put in a request for proposal. The questions are neutral to platform, so they work whether you lean toward Jitsi, BigBlueButton or a mix. Send the same questions to every candidate and ask each one for the same evidence: a sample architecture for your expected peak, a written description of how they tested it, and named examples of the settings they changed. Vague answers about capacity, authentication or upgrades are a signal in themselves. Score the answers side by side before any meeting about price.

Ask how each partner sizes capacity for peak load. For Jitsi, ask how many videobridges they would start with, how they would add more, and how the central server is provisioned. For BigBlueButton, ask how many servers they would pool and whether they would use Scalelite to distribute meetings. Ask how recording storage is calculated per term or per year, and where recordings land for playback and deletion. Ask how users behind restrictive firewalls connect, including whether they would deploy a TURN server and which ports they would open. Require the partner to name the ports and the hostname and certificate approach they expect, since both platforms depend on them.

Then ask how authentication is configured, such as JWT tokens, LDAP or an OpenID Connect provider, and how guest access is separated from staff access. Ask how load balancing is handled and how upgrades are scheduled around classes or meetings so that nothing breaks during a live session. Once answers are in, use them to write a fixed scope with deliverables and timelines agreed in writing before work starts. DeployOpen does not publish prices, and any quote follows that written scope, so ask every candidate to price the same scope.

Video conferencing RFP questions by area: sizing, firewalls, authentication and upgrades

How do you size videobridges or BigBlueButton servers for peak concurrency?

A good partner sizes from your peak concurrent meetings, participants per meeting and media mix (video, screen share, recording), then converts that into server counts. For Jitsi, ask how they size each Jitsi Videobridge against the vendor's scalable setup guidance, which suggests 4 or 8 CPUs with 8 GB RAM per bridge, plus a central server of 4 CPUs and 8 GB RAM. For BigBlueButton, ask them to confirm the 4.0 server minimums: at least 16 GB RAM with swap, 8 CPU cores with high single-thread performance, and 250 Mbit/s symmetrical bandwidth. Ask for the load test plan that proves those numbers against your real meeting pattern, and whether the sizing assumes a rehearsal before peak term or event dates.

How does recording storage and processing scale with usage?

Recording scales with the number of recorded hours, the resolution and the retention period, so the partner should model storage per term or per year, not per server. BigBlueButton 4.0 lists 500 GB of disk for recordings on a recording-enabled server (50 GB without recording), which is a starting point, not a plan. For Jitsi, recording runs through Jibri, and the partner should explain how many recorders run, what each one needs, and how recordings move off the media host. Ask who owns deletion, how consent and retention policies are enforced, and whether storage can be expanded without downtime. Request a written estimate of storage growth for your expected recorded hours.

How do users behind firewalls and restrictive networks connect?

The partner should map every port and protocol before design starts. For Jitsi, the quick start requires 80/TCP, 443/TCP and 10000/UDP, with 5349/TCP for TCP fallback and 3478/UDP for STUN as optional. For BigBlueButton, TCP 80 and 443 and UDP 16384 to 32768 must be reachable, and a TURN server is recommended for users behind restrictive firewalls. Ask how they deploy TURN, where it sits, which certificates it uses, and how they test from a restricted guest network. Confirm that the design works with a valid hostname and certificate, since self-signed certificates cause problems for many clients, especially on mobile.

Which authentication methods does the design support, and how are guests handled?

The answer should name the methods the partner will configure, not a general list. For Jitsi, the Docker guide documents internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, set through the .env file. The Jitsi handbook marks the older secure domain method as deprecated for new installations and recommends JWT token authentication with a separate anonymous domain for guests. For BigBlueButton, Greenlight v3 supports OpenID Connect, and the docs suggest Keycloak for Google, Microsoft and SAML logins. Ask how API secrets are stored and rotated, since BigBlueButton checksums depend on a shared secret that must never appear in a web page.

How does load balancing work across multiple media servers?

Ask the partner to show, in a diagram, where session routing decides which bridge or server hosts a meeting. Jitsi scales horizontally by adding Jitsi Videobridges, and the default install is already set up for that, so the question is how Jicofo assigns conferences and how the partner monitors bridge load. For BigBlueButton, pooling several servers behind Scalelite is the common pattern, and the partner should explain how Scalelite tracks capacity, drains a server for maintenance and fails over when a node goes down. Ask what happens to in-progress sessions during a failure, and whether the design requires sticky routing or shared storage for recordings.

How are upgrades scheduled around classes, term dates and meetings?

The partner should commit to a written change calendar that avoids live sessions, with a rollback plan for each release. Note that BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so moving between major lines usually means a clean server installation and a data migration plan. Ask how they track the 3.0 maintenance releases and the 4.0 line, how they test in a staging environment that matches production, and how they handle Jitsi build updates, which are tagged by build number. Confirm who performs upgrades, what happens to recordings during a move and what an upgrade window costs in your quote.

What does an implementation engagement cover, and what can we run ourselves?

Most DeployOpen engagements are fixed-scope, so the written scope should list design, installation, sizing validation, TURN and firewall setup, authentication, recording, integration, documentation, handover and any support retainer. Ask which items are one-time work and which recur, such as upgrades, monitoring and capacity changes. Your internal costs include staff time for operations, certificates, bandwidth and storage, which the partner can help you estimate. Ask for a quote that separates implementation from ongoing support, and confirm which skills your team needs to keep the platform running after handover.

Answers that should worry you in a video conferencing proposal

A vendor's answers to sizing, networking, security and upgrade questions reveal how much real operating experience sits behind the proposal. The cards below mark the replies that should slow a purchasing decision and prompt a follow-up in writing.

Sizing without a concurrency model

A proposal that quotes a server count without stating peak concurrent meetings, participants per meeting and the share of video versus audio-only users has not done capacity planning. Ask for the formula behind the number, the assumed peak, and how many videobridges or BigBlueButton servers are needed for the next doubling of load. The Jitsi scalable setup guide and BigBlueButton install requirements give concrete per-server baselines that a credible proposal should reference and adjust.

Recording promised without storage numbers

Recording is the cost driver most often left out of a first quote. A vendor who says recording is included but cannot state disk capacity per recorded hour, retention period, or where files land for playback and deletion has not designed it. Ask how storage grows per term or per year, how old recordings are purged, and whether recording workers run on separate hosts from the media servers.

Ignoring UDP media ports

A proposal that opens only ports 80 and 443 will leave audio and video broken for many users. Media travels over UDP, and the design must state the exact ranges, the firewall rules on both sides, and the TURN fallback for restrictive networks. Ask the vendor to list every port per component, and to show how they tested a user behind a corporate firewall before go-live.

Shared secrets exposed in web pages

BigBlueButton API calls are authenticated with a checksum built from a secret shared with the server, so that secret is effectively the admin key for the platform. A partner who plans to call the API from a public web page, a plugin or a browser-side script is creating a credential leak. Ask where the secret is stored, how it is rotated, which checksum algorithm is enforced, and how calls are made from the back end only.

Self-signed certificates for mobile users

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. A proposal that uses a self-signed or internal certificate without a trust plan for phones and tablets will fail for the users who most need guest access. Ask how the certificate chain reaches every device, who issues it, and how renewal is automated.

Direct upgrade from 3.0 to 4.0

A proposal that upgrades an existing BigBlueButton 3.0 server in place to 4.0 is not following the vendor's install guidance, which does not support direct upgrades from 2.6, 2.7 or 3.0 and recommends a clean server installation. The plan should include a fresh host, a migration of recordings and branding, and a test class before any cutover. Ask how upgrades are scheduled around timetabled classes and how rollback works if the new server fails.

How a partner should size videobridges or BigBlueButton servers for peak load

Sizing starts from peak concurrent meetings or classes and the number of participants in each, not from the total user count. A company with 5,000 licensed users may run only a few dozen meetings at the same time, while a university may have timetabled peaks where hundreds of classes start at the top of the hour. Ask the partner to write down the peak concurrency, the largest expected meeting size, the share of participants who turn on video, and whether recording or streaming runs during the peak. Each of these changes the load on the media servers, and a proposal that does not state them cannot be checked.

For Jitsi, the Jitsi 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. Videobridges scale horizontally by adding more, and the guide notes the default install is already configured for that. For BigBlueButton 4.0, the install documentation lists at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, and 250 Mbit/s symmetrical bandwidth per server, with 500 GB of disk for recordings or 50 GB without recording. These are published minimums, not capacity for a given meeting load. Ask the partner to state how many concurrent meetings and participants one bridge or server handled in their own tests, on which hardware, and with which video settings.

Ask for the partner's load test method in writing: the tool used to generate simulated participants, the media profile (audio only, camera on, screen share), the meeting sizes tested, the pass criteria for audio and video quality, and the point at which they stopped adding load. Then ask for every assumption behind any capacity figure, including network latency, codec settings, recording on or off, and headroom kept for failover. Fixed-scope proposals should tie the load test to a named deliverable and a repeat test after hardware or configuration changes, so the sizing is evidence rather than a claim.

Platform-specific questions for Jitsi Meet and BigBlueButton

Jitsi Meet is deployed as several cooperating services, and an RFP should make the partner show how each one is installed, hardened and kept current. The Debian or Ubuntu quick start and the official Docker setup both produce a web server, Prosody (the XMPP server), Jicofo (the conference focus) and one or more Jitsi Videobridge (jvb) media routers. The Docker setup also separates jigasi (SIP gateway) and jibri (recording and streaming) into their own containers.

Install method: Ask whether the partner deploys from the Debian/Ubuntu packages or from Docker, and which OS versions they support. The quick start supports Debian 12 (Bookworm) or newer and Ubuntu 24.04 or newer, and requires OpenJDK 17.
Component separation: Ask how prosody, jicofo and jvb are placed on hosts, and whether jvb nodes can be added without touching the central server.
Ports: Confirm that ports 80/TCP, 443/TCP and 10000/UDP are open, with 5349/TCP for TCP fallback and 3478/UDP for STUN as optional items.
Certificates: Ask how a valid domain certificate is issued and renewed. The handbook says self-signed certificates cause problems for working audio and video, especially on mobile clients.
Container hardening: For Docker, ask which release they pin. Since stable-11146 the containers run rootless with read-only filesystems, so confirm the partner keeps that configuration.

Check whether the partner's runbook covers every component, not only the web front end.

Recording scale and firewall traversal questions to settle early

Ask every partner how recording capacity is sized before anything else, because recording storage and bandwidth grow with the number of concurrently recorded sessions, not with the number of meetings held in a month. In Jitsi Meet, recording and streaming run through Jibri, which the official Docker setup places in its own container. That container has its own capacity limit, so a proposal that sizes only the videobridges has not sized recording. Ask how many simultaneous recordings the design supports per Jibri instance, how many instances are planned, and what happens to a recording request when all of them are busy. For BigBlueButton, ask how recording artifacts are stored on the 4.0 server and how much disk the proposal reserves. The BigBlueButton install documentation recommends 500 GB of disk for recordings, or 50 GB without recording, which the partner should adjust to the recording volume you actually expect.

Next, ask how users behind restrictive firewalls will connect. Browsers and clients that cannot reach media ports directly need a relay, typically a TURN server reached over TCP on port 443, or the 5349/TCP fallback that the Jitsi Debian and Ubuntu quick start lists as optional. The BigBlueButton install documentation also recommends a TURN server for users behind restrictive firewalls. Ask the partner which relay they will deploy, which ports they will open on your perimeter, whether the TURN service is inside or outside your network, and how they will test a session from a locked-down guest network before go-live. Confirm the exact port list against the current vendor documentation, since media ports differ between Jitsi (10000/UDP) and BigBlueButton (UDP 16384 to 32768).

Finally, settle the recording governance questions in writing. Ask where recordings land (object storage, a local volume, or a file share), how long they are kept by default and whether retention can differ by meeting type, and who can start, download and delete them. The answers should name the roles and the systems that enforce them, not just the intent. Some regulated meetings also create records that fall under retention rules such as those in 17 CFR 240.17a-4 or the audit controls in 45 CFR 164.312(b), so ask the partner to show where the deletion event is logged. Request these answers as a part of the written scope, because they change storage sizing, backup design and the evidence you can produce later.

How to run the evaluation with a shortlist of partners

This sequence turns a set of partner proposals into a comparable, tested decision. Each step produces a document or measured result that you can check against the same requirements, and the sequence ends with a fixed-scope statement of work for the approach you select.

Send one written requirements set to every partner
Your procurement or platform lead sends the same written requirements to each shortlisted partner. The set should cover expected concurrent meetings and classes, peak timing, recording and retention needs, guest and authentication rules, firewall and TURN conditions, and which network zones the media servers may use. Identical inputs make the answers comparable. The step is done when every partner has acknowledged receipt in writing and has named a technical contact for questions.
Collect sized architectures and test plans
Each partner returns a sized architecture for the platform it proposes, either Jitsi Meet or BigBlueButton, along with a test plan. The architecture should show how many videobridges or BigBlueButton servers are needed for your peak, how recording storage grows, where TURN and load balancing sit, and how upgrades are scheduled around live sessions. The test plan should name the load scenarios and the pass criteria. The step is done when each response shows its sizing assumptions in writing, so you can challenge them.
Run a pilot load test on the target network
Run a pilot meeting load test from inside the network where the platform will operate, not from a lab or a public cloud segment. Include users behind the firewall profiles you actually have, a sample of guest connections, and recording switched on for part of the run. Your team or the partner records CPU, memory, bandwidth, and dropped audio or video at each stage. The step is done when the measured results are documented and show whether the proposed sizing holds under the agreed peak.
Score each response against one table
Score every partner response against the same table, with a row for each requirement and a column for each evidence source: the written answer, the pilot result, and any reference you verified. Weight criteria that your industry or deployment constraint makes mandatory, such as authentication options, recording location, and encryption behavior. Record gaps as open questions rather than assumptions. The step is done when each row has a score and a short note, and the reviewers have signed off on the table.
Confirm open points before selection
Send the open questions from the scoring table back to the leading partners and ask for written answers. Typical open points include who maintains the platform version after go-live, how security patches are delivered, and what happens to recordings at deletion. Confirm any capability you cannot verify directly with the vendor or in your own environment before you rely on it. The step is done when no requirement in the table is marked unverified without a documented owner and next action.
Convert the chosen approach into a statement of work
Turn the selected approach into a fixed-scope written statement of work. It should list deliverables such as the installed platform, authentication configuration, load balancing, recording setup, documentation, and the acceptance tests from the pilot. It should also state the support model and what recurs after handover, such as upgrades and hosting costs. Ask for a quote that follows from this written scope. The step is done when legal, security, and the business owner have approved the statement of work and the acceptance criteria match the pilot results.

How to score partner answers across sizing, security and operations

This table gives a neutral 0 to 3 scale for judging how a video conferencing partner answers each RFP area, from sizing evidence to upgrade planning. Score each answer against the criterion, then weight security and operations criteria according to your own risk, classes or meetings, and regulatory needs. A partner that scores 3 on sizing and authentication but 0 on upgrade planning has shown you a gap that will surface during the first BigBlueButton 4.0 or Jitsi release window, not during the demo.

Criterion	Score 3 (full answer)	Score 1 (partial answer)	Score 0 (missing answer)
Sizing evidence for peak load	States concurrency assumptions, per-bridge or per-server capacity from a load test, and the headroom rule for adding capacity	Gives vendor-default numbers or a single server count without the peak scenario or test method	Answers with a general claim that the platform scales, and no figures
Recording design	Explains where recordings are stored, storage per hour at the target resolution, retention, deletion and how recording load is isolated from meetings	Recording is mentioned but storage sits on the same node or the retention rule is left to the customer	Recording is not addressed or is quoted as an add-on without a design
Firewall and TURN design	Lists required ports (for example 80/TCP, 443/TCP, 10000/UDP for Jitsi; 16384 to 32768/UDP for BigBlueButton), a TURN plan for restrictive networks and a tested fallback path	Ports named but no TURN plan, or TURN described without who hosts it and where it sits	No port list, or relies on users making firewall exceptions ad hoc
Authentication model	Names the method (for example JWT tokens, LDAP, OpenID Connect through Greenlight), separates member and guest access, and explains secret handling	Names one method with no guest or secret-management design	Relies on shared links only, or on the deprecated secure domain method without a migration plan
Load balancing and scaling	Explains horizontal scaling of Jitsi videobridges or pooling of BigBlueButton servers (for example through Scalelite), health checks and failover	Says load balancing is included but does not describe placement logic or failure behavior	No design for distributing meetings across nodes
Upgrade plan around schedules	Describes a maintenance window tied to the class timetable or meeting calendar, a staging rehearsal, rollback steps and whether direct upgrades are supported for the target version	Gives a generic patch cadence without linking it to calendars or rollback	Says upgrades are done when the customer asks, with no window or rollback
Compliance readiness evidence	Provides configuration baselines, access logs, recording and retention records and transmission settings that map to the controls your assessor will ask about	Provides a policy document but no system-level evidence an assessor could sample	Cannot name the evidence it would produce
Operational ownership and support	Defines who monitors, who responds, what is documented and how knowledge transfers to your team, in the written scope	Support is described as available without response roles or documentation	Support scope is undefined or left to the customer

What compliance evidence the answers should produce

For regulated buyers, every answer to the questions above should produce evidence that an assessor or examiner can inspect, not a verbal assurance from the vendor. Ask each partner to name the artifact behind each answer: a configuration export, a log sample, a test record, a runbook or a signed change ticket. For HIPAA-covered meetings, the relevant anchors are the audit controls in 45 CFR 164.312(b), which require mechanisms that record and examine activity in systems containing ePHI, and the transmission security standard in 164.312(e)(1), which requires protection against unauthorized access to ePHI sent over a network. Ask how Jitsi or BigBlueButton logs join, leave, recording and administrative events, where those logs are stored, who can read them and how long they are kept. Ask for a sample log extract from a test meeting so you can see the fields before you commit.

Where recordings or chat transcripts are business records, the retention question becomes concrete. SEC Rule 17a-4(b)(4) requires broker-dealers to preserve communications relating to the business for not less than three years, so the partner should explain where BigBlueButton or Jibri recordings land, how they are copied to write-protected or immutable storage if your policy requires it, and how deletion is blocked during a hold. Confirm with your compliance team whether the rule applies to the meetings in scope at all, because that decision drives the storage design and cost. The partner should show a tested restore of a recording from the archive, with its metadata and retention label intact.

DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those determinations. In the RFP, ask the implementation partner to deliver a control mapping, configuration baselines, logging and retention settings, and test evidence in a form your assessor can review. Ask who owns each control after handover, how often evidence is refreshed, and what happens to the evidence when the platform is upgraded. A partner that cannot produce these artifacts before work starts is describing a deliverable, not offering evidence.

Video conferencing implementation partner FAQ: cost, time and effort

What drives the cost of a self-hosted video conferencing platform?

Cost comes from four places: the servers and bandwidth that carry meetings, the storage that holds recordings, the TURN relays that reach users behind firewalls, and the people who run the platform. Hardware and bandwidth recur every month or year, while design, installation, integration and hardening are usually one-time. Peak concurrency is the main driver, because you must provision for the busiest hour, not the average. Ask any partner for a quote that separates one-time setup from recurring operations, names who owns each server and cloud account, and states how recording storage grows per term or per year.

How much server capacity does BigBlueButton 4.0 need per machine?

The BigBlueButton 4.0 install documentation lists the minimum for one server: 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. These figures set the baseline for each server you buy or rent, so multiply them by the number of servers your peak concurrency requires. Ask the partner to show the capacity model for your largest expected class or meeting, including how many servers stay idle for failover.

How long does a fixed-scope video conferencing engagement take?

No duration is fixed across all deployments, so the timeline depends on the agreed scope, the number of meeting or classroom sites, integrations with identity and learning systems, and how quickly your team can provide hosts, certificates and firewall changes. Most engagements are fixed-scope, meaning scope, deliverables and timelines are agreed in writing before work starts. Ask the partner for a written schedule with milestones for infrastructure, authentication, testing with pilot users and go-live, and ask which tasks depend on your change approvals.

What does the work need from our network and staff?

Expect to supply network and security decisions before build starts. BigBlueButton requires TCP ports 80 and 443 and UDP ports 16384 to 32768 to be reachable, plus a valid hostname for SSL and Docker for sandboxed document conversion. Jitsi Meet needs ports 80 and 443 over TCP and 10000 over UDP, and HTTPS with a proper domain certificate is necessary for working audio and video. A TURN server is recommended for users behind restrictive firewalls. Your team will also need to approve firewall rules, DNS records, certificate issuance and the identity provider connection, so confirm who holds each of these.

Can our own IT team run a self-hosted video platform after go-live?

Yes, many teams operate these platforms internally, but the work is recurring rather than one-time. Ongoing tasks include patching, certificate renewal, capacity checks before peak periods, backup of configuration and recordings, monitoring of media servers and upgrades. BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so a clean server installation is recommended, which changes how migrations are planned. Before you decide, ask whether your team has Linux, Docker and real-time media skills, who is on call for class hours, and whether the partner offers a retainer for upgrades and support.

Do we pay for the software license, and what do the vendors charge?

Jitsi Meet is licensed under Apache-2.0 and BigBlueButton under LGPL-3.0, so the core software carries no license fee. Costs instead come from infrastructure, setup, integration and support. If you want hosting or commercial support from the vendor side, the BigBlueButton project points to BigBlueButton Inc., and Jitsi is a trademark of 8x8, Inc., which offers JaaS. Ask any partner to state in writing which third-party services are included, which are optional and which are billed separately.

What should we ask a partner to put in the written scope?

Ask for a scope that names the platform and version, the number of servers and their sizing basis, the recording and retention settings, the authentication method, integrations with your identity or learning systems, the testing and load test plan, the handover documentation and the post-go-live support terms. Ask how the partner will prepare evidence for any compliance assessment, while remembering that DeployOpen prepares systems, controls and evidence but does not issue audit reports or certifications. Any exclusions should be listed as explicitly as inclusions.

How DeployOpen scopes and delivers video conferencing RFP questions

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source video platforms inside your own cloud accounts, data centers or air-gapped networks. For an RFP evaluation, we turn your questions on capacity, recording, firewall traversal, authentication, load balancing and upgrades into a written scope, a test plan and evidence you can compare across bidders.

How we scope

Written scope lists the platform options (Jitsi Meet or BigBlueButton) and the peak meeting and participant counts you need to evaluate.
Scope defines how each RFP question will be answered: design documents, lab tests or reference configurations for your environment.
Scope names which network zones, firewall rules, TURN requirements and identity sources are in or out of the engagement.

How we build

We build a lab or staging deployment that mirrors your planned topology, including videobridge or BigBlueButton server sizing against your peak load.
We test firewall traversal from representative user networks, confirming the TCP and UDP ports each platform needs and the TURN fallback path.
We exercise authentication options such as JWT tokens or OpenID Connect, and record recording storage behavior and load balancing results.

How we hand over

Deliverables include a written answer to each RFP question, architecture diagrams, sizing worksheets and the test results behind each answer.
Documentation covers the upgrade procedure, including whether a clean server install is required between major releases.
Handover names the configuration files, secrets handling steps and operational runbooks your team keeps after the evaluation ends.

How we support

Fixed-scope engagements end with agreed deliverables, and any follow-on work is quoted from a separate written scope.
Ongoing support, upgrades and continuous testing are available as a retainer if you select a platform and want DeployOpen to operate it.
Before choosing a partner, ask each bidder who holds the upgrade schedule, the on-call model and the evidence they will provide for audits.

Video conferencing RFP questions