Rocket.Chat video calls with Jitsi or BigBlueButton: what the apps connect
A team that wants calls inside Rocket.Chat without media leaving its infrastructure needs two parts: a video server that the organization runs, and a Rocket.Chat app that starts and joins meetings on that server. The Jitsi and BigBlueButton marketplace apps supply the second part, so a call started from a channel or direct message opens a meeting hosted on the client's own video server. Rocket.Chat does not carry the audio or video itself. Confirm the current app listing, its supported Rocket.Chat versions and its install steps on the Rocket.Chat marketplace before you plan around them, because app behavior can change between releases.
A Jitsi Meet deployment has four core parts: a web server (nginx or Apache) that serves the web application, the Prosody XMPP server that handles signaling and accounts, Jicofo, the conference focus that creates and manages conferences, and one or more Jitsi Videobridge (JVB) media routers that carry the streams. The official Docker setup separates these into web, prosody, jicofo and jvb containers, and adds jigasi (SIP gateway) and jibri (recording and streaming) as optional containers. Ask the app's maintainer which of these components it calls, and which authentication mode it expects. The Jitsi handbook recommends JWT token authentication for new installations, so check that the app supports it before you choose a configuration.
A BigBlueButton server is a full virtual classroom stack, with audio, video, slides with annotations, chat, screen sharing, polling, a multi-user whiteboard, shared notes and breakout rooms. The integration relies on its API. Every API call carries a checksum computed from a secret shared with the server, and the BigBlueButton API documentation warns never to embed that secret in a web page. The app must hold the secret on the server side, and your team should rotate it through a documented process. Greenlight, the optional front end, and LTI support can be installed on the same server through the install script. Confirm whether the app needs either one or only the core API.
Several decisions come before installation. Choose one Jitsi or BigBlueButton server per environment, or separate servers by business unit, and decide who administers each. Decide whether the chosen video server will be the only meeting option, because each app adds its own call button. Plan for the Rocket.Chat release calendar, since version durability rules say that after end of life a version gets no security fixes and cloud services such as the Marketplace stop working. A Rocket.Chat upgrade may therefore require an app update or a new app version, so schedule both together.
Verify the setup with a test that matches your data handling needs. Start a call from a channel, a direct message and a private group, then join from a browser and a mobile client. Confirm that a meeting joins the video server you chose and not a public instance such as the free Jitsi service. Check the hostnames in network logs and firewall records to confirm that media traffic stays within your infrastructure. Record which app version, Rocket.Chat version and video server version passed the test, so the same checks can run after each upgrade.
What Rocket.Chat video calls need before setup starts
Both video options need a supported Rocket.Chat release, a dedicated host, a public hostname and open network paths, and most delays come from items decided too late. The cards below list what to confirm before setup starts and who provides each item. The Rocket.Chat version and plan decisions come first because they set which marketplace app and features you can use.
Rocket.Chat version and support window
Pick a Rocket.Chat line that is still inside its support window before you plan anything else. Rocket.Chat 8.9.0 was published on October 5, 2026. Standard releases are supported for 6 months and LTS releases for 12 months. After end of life, a version gets no security or bug fixes, and cloud services such as Marketplace stop working, which affects how the video apps are installed and maintained. Your team confirms the target line, and DeployOpen checks it against your upgrade schedule.
Paid plan needed for the integration
Rocket.Chat's free Starter plan allows up to 50 users and includes LDAP, Active Directory, single sign-on and multi-factor authentication. Paid plans add capabilities such as LDAP and SAML user group mapping, tamper-evident audit trails and built-in failover. Whether the Jitsi or BigBlueButton marketplace app is supported on the plan you hold is a question to confirm with Rocket.Chat before purchase. Your procurement team owns that answer, and the written scope should name the plan.
Jitsi host and firewall ports
The Jitsi Debian or Ubuntu quick start supports Debian 12 (Bookworm) or newer and Ubuntu 24.04 or newer, and it requires OpenJDK 17. The host must allow 80/TCP and 443/TCP for the web app and 10000/UDP for media. Port 5349/TCP for TCP fallback and 3478/UDP for STUN are optional but help users on restrictive networks. Your infrastructure team provides the server and firewall rules, and DeployOpen installs the stack. Confirm the OS release against the current quick start before the build date.
Jitsi domain certificate
The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video. It warns that self-signed certificates cause problems, especially with mobile clients. Choose the public hostname now, because the DNS record, the certificate and the server configuration all depend on it. Your team or your certificate authority provides the certificate, and DeployOpen configures the web server with it. Confirm the renewal process before go-live, since an expired certificate stops calls from connecting.
BigBlueButton 4.0 host sizing
BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit and needs at least 16 GB of RAM with swap and 8 CPU cores with high single-thread performance. Disk requirements are 500 GB with recording or 50 GB without, and bandwidth is 250 Mbit/s symmetrical. Direct upgrades from 2.6, 2.7 or 3.0 are not supported, so plan a clean server installation. Your infrastructure team provides the sized host, and DeployOpen installs and configures BigBlueButton on it.
BigBlueButton ports and hostname
BigBlueButton needs TCP ports 80 and 443 and UDP ports 16384 to 32768 reachable from users. It also needs a valid hostname for SSL, so the name must be decided before the certificate is issued. Docker is required for sandboxed LibreOffice document conversion, and a TURN server is recommended for users behind restrictive firewalls. Your network team opens the port range and DNS records, and it should confirm that cloud and perimeter policies allow the full UDP range.
How to set Rocket.Chat video calls to use your own Jitsi server
This sequence takes a clean server, a trusted domain and certificate, and an authenticated video service through to a working call from inside Rocket.Chat. Each step closes with a check, so you know whether to continue before you configure the next layer. The Jitsi and BigBlueButton paths share the first steps and split at authentication and secret handling.
Build a clean server for the video platform
Start with a host that carries no other workload. For Jitsi, the Debian and Ubuntu quick start supports Debian 12 (Bookworm) or newer and Ubuntu 24.04 or newer, and it requires OpenJDK 17. For BigBlueButton 4.0, the install docs call for Ubuntu 24.04 64-bit, at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, and 250 Mbit/s symmetrical bandwidth. BigBlueButton does not support direct upgrades from older branches, so a clean installation is the starting point. Your infrastructure team builds the machine in your environment and checks it against these requirements before anything is installed. This step is done when the host is patched, reachable over SSH, and meets the stated minimums.
Configure the domain and certificate
Create a DNS name for the video server and issue a certificate that your users' browsers and mobile clients trust. The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video, and it warns that self-signed certificates cause problems, especially on mobile clients. BigBlueButton also needs a valid hostname for SSL. Open TCP 80 and 443 to the server, and open UDP 10000 for Jitsi media. For BigBlueButton, confirm the UDP range 16384 to 32768 is reachable. This step is done when the name resolves from inside and outside your network and the certificate chain validates.
Confirm the server works in a browser
Open the server address in a current browser on a workstation and start a test meeting by yourself. Check that the page loads over HTTPS without certificate warnings and that the camera and microphone prompts appear. Then join the same meeting from a second device on the same network and confirm that audio and video flow in both directions. For BigBlueButton, run the post-install verification described in the install documentation for your release before you continue. This step is done when a standalone meeting works end to end without errors, and the result is saved in your change record.
Choose the authentication mode
Decide how people will join before you change any configuration. The Jitsi handbook marks the older secure domain method, which relies on username and password room creation, as deprecated for new installations and recommends JWT token authentication. Use a separate anonymous domain for guests, so that unauthenticated users can join the rooms they are invited to. If you run the Jitsi Docker setup, you select the mode in the .env file, and the options include internal XMPP accounts, JWT, LDAP, Matrix verification and a hybrid Matrix plus JWT mode. Record the chosen mode, the token audience and issuer values, and where the token secret is held. This step is done when the decision and its settings are approved and the secret sits in your secrets manager.
Install the matching Rocket.Chat app
Install the Rocket.Chat marketplace app that matches your video platform, either the Jitsi app or the BigBlueButton app. Before you install, confirm that the app version is compatible with your Rocket.Chat release, using the app listing and the Rocket.Chat documentation for your line. Rocket.Chat states that an unsupported version stops working with Marketplace services, so confirm your server version is still within its support window. A workspace administrator installs the app from the Marketplace. This step is done when the app appears as installed and enabled in the administration area, with its version recorded.
Enter the server settings in Rocket.Chat
In the app settings, enter the public address of your video server and the authentication values for the mode you chose earlier. For JWT, that means the shared token secret along with the matching audience and issuer values. For BigBlueButton, it means the server URL and the shared secret. Keep the default video option off for direct and group rooms until the test in the final step passes. Save the settings and create a call link from a test room. This step is done when the settings save without errors and the test room generates a call link that opens the meeting for an authenticated user.
Keep the BigBlueButton secret server-side
This step applies only if you chose BigBlueButton. The shared secret signs every API call, so it must stay on the server side and never appear in a web page. The BigBlueButton API documentation warns against embedding it in client code. Checksums use SHA-256 by default, SHA-1 for legacy use, and SHA-384 or SHA-512 since version 2.5. Store the secret in your secrets manager and limit who can read the app configuration. If you also need a separate front end, the bbb-install.sh script can install Greenlight or LTI support on the same server. This step is done when a review of the page source and network requests in a browser shows no shared secret.
Test calls from two networks
Open a test room from your corporate network and then from a second network, such as a mobile hotspot or a home connection. Start a call with a user on each side and confirm that the link opens without a certificate warning, that audio and video flow both ways, and that a guest can join through the anonymous path if you enabled it. If some users sit behind restrictive firewalls, test from one of those networks as well, since the BigBlueButton documentation recommends a TURN server for them. This step is done when both networks join, media flows in both directions, and the results are recorded with the Rocket.Chat and video platform versions.
Which users, rooms and permissions map to each video server
This table compares how each Rocket.Chat identity, room type and role reaches Jitsi and BigBlueButton, and where each mapping is set. Read each row as a question to answer for your app version, and check items marked Confirm against the release you deploy before testing. The main takeaway is that moderator and guest behavior depend on the exact token claim or API parameter the app sends, so test each path with a real user, a moderator and an external guest.
| Mapping | Jitsi (JWT and .env) | BigBlueButton (API calls) |
|---|---|---|
| Display names and avatars | Name and avatar are passed in the JWT user context if the app includes them. Confirm the claim names for your app version. | Name is sent as a parameter on create and join calls. Confirm whether the app sends an avatar, since BigBlueButton does not show one by default. |
| Direct messages versus channels | Room name is derived from the Rocket.Chat room. Confirm whether the app uses the room ID or the room name, and whether DM rooms get distinct names. | Each call needs a unique meeting ID. Confirm that DMs and channels map to separate meeting IDs and that a meeting is not reused unintentionally. |
| Moderator roles | Moderator status is set by a flag in the JWT user context. Confirm which Rocket.Chat roles or room owners the app maps to moderator. | Role is set by which password the join call uses, moderator or attendee, chosen when the meeting is created. Confirm how the app assigns each password. |
| Guest access and anonymous domain | Guests join through a separate anonymous domain configured in the Jitsi setup, without a token. Confirm how the app decides a user is a guest. | Guests join with an attendee link or password. Confirm whether the app issues attendee links to external users and whether they can start meetings. |
| Shared secrets and signing | The JWT is signed with a secret that Rocket.Chat and the Jitsi components must share. Store it in the Jitsi .env file and the app configuration only. | Every API call carries a checksum built from the server secret. Confirm the hash algorithm the app uses for your BigBlueButton version and never expose the secret in a page. |
| Where each mapping is set | Authentication mode and JWT settings live in the Jitsi .env file. Provider selection and credentials sit in the Rocket.Chat administration area. Confirm setting names for your release. | Meeting parameters are set by the app server when it calls the API. Confirm which options, such as recording, are exposed in Rocket.Chat settings and which need code changes. |
| Recording and permissions | Recording runs through a separate recording component and needs its own permission check. Confirm whether the app can start recording and who may do so. | Recording is a create-time option. Confirm whether the app sends it, and whether only moderators can start or stop recording in your version. |
Securing video links so only the right people join
Video calls in Rocket.Chat are only as private as the links that open them. The six areas below cover transport security, how meeting access is granted, the secrets that sign those requests, and the host settings that control who can reach the media servers. Review them together before go-live, because a gap in any one of them can let an outsider join a room or reach the server configuration.
HTTPS with a valid certificate
Jitsi and BigBlueButton both need a valid TLS certificate on a proper domain name. The Jitsi handbook states that HTTPS with a domain certificate is necessary for working audio and video and warns that self-signed certificates cause problems, especially with mobile clients. BigBlueButton also requires a valid hostname for SSL. Confirm that every browser and mobile client your staff use trusts the certificate chain, and that renewal is automated before expiry.
JWT authentication for Jitsi
JWT token authentication lets Rocket.Chat or your own service issue signed tokens, so only authorized users can create or join rooms. The Jitsi handbook marks the older secure domain method, which relies on usernames and passwords for room creation, as deprecated for new installations. In the Docker setup, the authentication mode and token settings live in the .env file. Keep a separate anonymous domain for guests, and confirm how the marketplace app passes user identity and moderator rights into each token.
BigBlueButton checksums and shared secret
Every BigBlueButton API call must carry a checksum computed from a secret shared with the server. SHA-256 is the default, SHA-1 remains for legacy use, and SHA-384 or SHA-512 are available since version 2.5. Choose the strongest algorithm that both the server and the marketplace app support, and confirm which one the app sends. The shared secret must never appear in a web page or client-side setting, because anyone who reads it can create and join meetings.
Media port exposure
Publish only the ports each media stack needs. The Jitsi Debian and Ubuntu quick start lists 80/TCP, 443/TCP and 10000/UDP as required, with 5349/TCP for TCP fallback and 3478/UDP for STUN as optional. BigBlueButton needs TCP 80 and 443 and UDP 16384 to 32768, and its docs recommend a TURN server for users behind restrictive firewalls. Test reachability from a client on a restricted network, not only from inside your own perimeter.
Rootless and read-only Jitsi containers
The official Jitsi Docker setup runs web, prosody, jicofo, jvb, jigasi and jibri as separate containers. Since release stable-11146, these containers run rootless with read-only filesystems. Confirm that your deployed release includes this change. Then test recording and SIP components, because a read-only root filesystem blocks writes outside the volumes you declare. Review volume mounts and any custom image layers your team adds.
Server administrator role holders
Server administrator access controls the Jitsi and BigBlueButton hosts, their secrets, and the .env and configuration files. Decide in writing which named people hold this role and how access is granted and removed. Confirm whether these administrators are separate from Rocket.Chat workspace administrators. Keep the list short, require individual accounts with multi-factor authentication, log changes to shared secrets and token signing keys, and review the list whenever staff change roles.
How to test Rocket.Chat video calls before users rely on them
Run every call path below against the exact Rocket.Chat version, video app version and client builds your users will run, and file the results before announcing video calls. Start with a one-to-one call between two internal accounts, then a multi-party call with at least three participants, so you see how the video server handles several media streams at once. Repeat both calls twice: once started from a channel and once from a direct message, because the invitation path, notifications and room permissions can differ between them. For each case, keep the room identifier, server time, screenshots from both ends showing audio and video in each direction, and the video server log lines for the session. Record the duration of each call and any reconnects, because a call that connects but drops audio after a minute has still failed the test.
Guest access and restrictive networks test the parts of the design that internal users never touch. Invite a guest from a network outside your perimeter, such as a home connection or a partner network, and confirm whether that guest can join under your configured authentication model. Check that the video domain presents a valid HTTPS certificate, because the Jitsi handbook states that working audio and video requires one. Then test a user behind a firewall that restricts UDP. BigBlueButton recommends a TURN server for these users, so run the test with and without TURN and record which path the media takes, using browser connection statistics where your browser provides them. Compare the result against the ports you opened: 10000/UDP and 443/TCP (with 5349/TCP as TCP fallback) for Jitsi, and 16384 to 32768/UDP for BigBlueButton. Keep the firewall rules, the network details of each test client and the pass or fail result for each path.
Desktop and mobile clients need their own pass because they fail in different ways from the browser. Test the current official desktop app, the current mobile app and a supported browser through the full sequence: signing in, starting a call from a channel and from a direct message, joining from a notification, and granting camera and microphone permissions. Record the client version, operating system, device model and video app version for each run. Then test one client version behind your target, so you learn how older builds behave before you ask users to update. Rocket.Chat states that unsupported versions may lose the ability to connect with the official mobile and desktop clients, so check the support status of every version you test against the version durability documentation. Mobile devices are also the most likely place to surface certificate problems, so include at least one mobile test that uses your production certificate chain.
Finish with a forced restart of the video server during a live call. Restart the Jitsi services or the BigBlueButton host while two or more test calls are running, then record what participants see, how long recovery takes, and whether new calls succeed afterward without restarting Rocket.Chat. Expect calls in progress to end, and decide in advance what message users should see. Load testing comes after the functional tests and should start from the vendors' sizing guidance, which your team should confirm for its own concurrency target. 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. The BigBlueButton 4.0 install documentation lists at least 16 GB RAM with swap, 8 CPU cores with high single-thread performance and 250 Mbit/s symmetrical bandwidth for a server. Keep each load test result alongside the exact configuration it ran on.
Why video calls fail in Rocket.Chat and how to fix them
This table lists common video call failures when Rocket.Chat uses the Jitsi or BigBlueButton marketplace apps. Each row gives the symptom and likely cause, the first check to run, and the fix. Work through the rows in order, because certificate and port faults can hide later problems. Most failures trace to certificates, closed media ports, or a version that has fallen out of support, and each can be confirmed before any change is made.
| Symptom and likely cause | Check first | Fix |
|---|---|---|
| Audio or video not working because the certificate is self-signed or invalid | Confirm the certificate covers the public hostname and chains to a trusted authority | Install a valid domain certificate. The Jitsi handbook says HTTPS with one is necessary for working audio and video. |
| Media blocked because Jitsi UDP 10000 is closed | Confirm UDP 10000 is reachable from user networks to the videobridge host | Open 10000/UDP. The Jitsi quick start also lists 5349/TCP for TCP fallback and 3478/UDP for STUN as optional. |
| Media blocked because BigBlueButton UDP 16384 to 32768 is closed | Confirm the full UDP range is open in the cloud security group and host firewall | Open UDP 16384 to 32768. BigBlueButton requires this range to be reachable from users. |
| Calls fail behind strict firewalls with no TURN path | Test a join from a restricted network to see whether media can reach the server | Deploy a TURN server for BigBlueButton. The install docs recommend one for users behind restrictive firewalls. |
| BigBlueButton checksum errors after the shared secret changed | Compare the secret stored in the Rocket.Chat app settings with the server secret | Update the app setting to the new secret, save, and retest a join. Never embed the secret in a web page. |
| Upgrade from BigBlueButton 2.6, 2.7 or 3.0 fails or is unsupported | Record the installed version and Ubuntu release before changing anything | Plan a clean BigBlueButton 4.0 install on Ubuntu 24.04. The install docs say direct upgrades from these versions are not supported. |
| Calls break after the Rocket.Chat version falls out of support | Check the version against the Rocket.Chat support dates and the Marketplace app status | Upgrade to a supported release. Unsupported versions stop receiving security fixes and may lose client connections. |
Keeping Rocket.Chat and the video server in step after go-live
Keeping Rocket.Chat, its mobile and desktop clients, and the video server in step is an ongoing operating task, so it needs one shared upgrade calendar from the day of go-live. Rocket.Chat supports standard releases for 6 months and LTS releases for 12 months. After end of life, a version receives no security or bug fixes, and cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. Rocket.Chat also says unsupported versions may lose the ability to connect with the official mobile and desktop clients, so the app versions on users' devices belong on the same calendar as the servers. Record each component's current version, its support end date, the people who approve upgrades, and the test workspace where changes are tried first. Review that record at every release cycle.
Rocket.Chat publishes patch releases for older supported lines as well as new versions. Release 8.9.0 was published on October 5, 2026, and patch releases such as 8.6.3 and 8.5.4 followed on October 16, 2026 for the older lines. Decide which line your workspace runs and name the person who watches its release notes. Test each patch in staging before it reaches production. Check the Jitsi and BigBlueButton Marketplace apps for compatibility with the Rocket.Chat version you are moving to, and confirm that compatibility in each app's release notes before you upgrade. Where possible, schedule chat server and client updates in the same window, so users run a mix of versions for as short a time as possible.
BigBlueButton 4.0.0 was released on October 14, 2026, and it installs on Ubuntu 24.04 64-bit. The project does not support direct upgrades from 2.6, 2.7 or 3.0, so moving to 4.0 means a clean server installation on new hardware or a new virtual machine. That is followed by a cutover of the Rocket.Chat integration settings, DNS records and the shared secret used for API checksums. Servers already on the 3.0 branch continue to receive maintenance releases, such as 3.0.39 on October 2, 2026, so they can keep running while the 4.0 build is validated. Confirm the end of that maintenance period with the BigBlueButton project's current guidance. Decide how recordings on the old server will be retained, moved or archived before that host is retired, and check the 4.0 hardware requirements against your planned capacity first.
For Jitsi, track the stable release tags of jitsi-meet and the Docker images you deploy. The repository lists stable/jitsi-meet_11248, published September 14, 2026, and the official Docker setup has run its containers rootless with read-only filesystems since stable-11146. Before any update, read the release notes for changes to the .env authentication settings, including JWT, LDAP and Matrix options, because a change there can block users from joining rooms. Capacity needs its own watch. Monitor CPU, memory and bandwidth on each videobridge, along with concurrent participants, and compare them with the sizing guidance in the scalable setup guide, which suggests 4 or 8 CPU with 8 GB of RAM for each bridge. Scale by adding bridges, since the default install is already configured for horizontal scaling.
Decide early when the chat server itself needs more than one instance. Rocket.Chat's reference architectures suggest one instance with a MongoDB replica set for up to 500 concurrent users, multiple load-balanced instances linked by NATS above 500, and microservices on Kubernetes with the official Helm chart above 5,000. The multi-instance and microservice designs require a paid plan, and the free Starter and Community options carry their own user limits. Ask Rocket.Chat to confirm how it counts concurrent users, then measure your own peak from logs and monitoring before relying on headcount alone. Video capacity is planned separately. The Jitsi bridges and BigBlueButton servers have their own limits, so a chat threshold does not tell you when the video tier needs more capacity.
Questions buyers ask before hiring help with Rocket.Chat video calls
How much does hiring help with Rocket.Chat video calls cost?
There is no published price for this work. DeployOpen does not publish a price list, and a quote follows from a written scope agreed before work starts. Most of the cost is labor: planning, building the Jitsi or BigBlueButton servers, connecting them to Rocket.Chat, configuring authentication, handling DNS and certificates, testing and handing over documentation.
The main cost drivers are the number of video platforms you choose, the number of concurrent participants you expect, the authentication design (JWT, LDAP, OpenID Connect or a Matrix-based method), the network and firewall work your environment needs, the testing scope, and who will operate the servers after go-live. Setup is largely one-time. Hosting, certificate renewal, patching and upgrades recur after the project closes. Ask each bidder to price these items separately.
How long does it take to add Jitsi or BigBlueButton to Rocket.Chat?
Duration depends on the scope and your environment, and no fixed timeline applies to every deployment. The written scope sets the schedule. Work moves faster when servers, DNS names, certificates and firewall rules are ready before the build starts.
BigBlueButton 4.0 requires a clean server install on Ubuntu 24.04 64-bit, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so an existing BigBlueButton host usually needs a fresh install. The Jitsi quick start targets Debian 12 or newer or Ubuntu 24.04 or newer and requires OpenJDK 17. Testing with pilot users and the approval steps in your change process often take longer than the installation itself. Ask the provider to list dependencies and client-side tasks in the quote so you can check the schedule against your own calendar.
Can our own team run Jitsi or BigBlueButton for Rocket.Chat?
Yes, if your team already runs Linux servers, reverse proxies, DNS, certificates and firewall rules, and can keep them patched. Jitsi's quick start covers a Debian or Ubuntu install with nginx or Apache, Prosody, Jicofo and Jitsi Videobridge, and its Docker guide splits these into separate containers. BigBlueButton 4.0 has its own install script and specific hardware and port requirements.
The parts teams most often underestimate are getting media ports open through NAT, configuring the authentication link to Rocket.Chat, and keeping the video servers current alongside Rocket.Chat's own upgrade cycle. Decide early who responds when a call fails. If your team cannot own that work, a fixed-scope build with handover followed by a retainer for ongoing support is one option to compare.
What does our team need to provide before video work starts?
Your team supplies the inputs the build depends on, and having them ready shortens the work. Typical inputs include:
- A DNS name for each video service and a valid certificate for it. Jitsi's handbook says 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.
- Firewall changes for the ports each platform needs. Jitsi needs 80/TCP, 443/TCP and 10000/UDP, and BigBlueButton needs TCP 80 and 443 and UDP 16384 to 32768.
- Server capacity in your cloud account or data center.
- Administrator access to your Rocket.Chat workspace and its Marketplace.
- Identity provider details if you want single sign-on.
- A named decision owner and a pilot group of users for testing.
Which factors change server sizing for self-hosted video calls?
Sizing depends on how many people join at once, how long calls run, whether recording is on, and how many video platforms you operate. Jitsi's 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, and it notes that videobridges scale horizontally by adding more.
BigBlueButton 4.0 needs at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 250 Mbit/s symmetrical bandwidth, and 500 GB of disk for recordings (50 GB without recording). Rocket.Chat's reference architectures suggest one instance with a MongoDB replica set for up to 500 concurrent users in Rocket.Chat itself, with multi-instance designs above that. These figures are starting points. Confirm your concurrency target and run load tests before you size production.
Who maintains the video servers after go-live, and what recurs?
Ownership is set in the scope, and recurring work is the cost buyers most often underestimate. Recurring tasks include operating system patching, Jitsi and BigBlueButton version updates, certificate renewal, backups, monitoring of media ports and capacity, and testing after each Rocket.Chat upgrade.
Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months. After end of life, a version receives no security or bug fixes, and cloud services such as the Marketplace stop working. Rocket.Chat also says unsupported versions may lose the ability to connect with its official mobile and desktop clients. A Rocket.Chat upgrade can therefore force a video change. Ask whether your team or DeployOpen will operate each server, and whether that work sits under a retainer.
What should a written quote for video calls include?
A useful quote lists what is included and excluded, so you can compare bids on the same basis. Ask for:
- Platforms in scope, Jitsi, BigBlueButton or both, with the Rocket.Chat versions and plan tier they target.
- Server design, including the number of video servers, expected concurrency and sizing assumptions.
- Authentication method and who supplies the identity provider.
- Certificate, DNS and firewall work, and who performs each task.
- Testing scope, such as functional calls, load and failover tests.
- Documentation and knowledge transfer at handover.
- Operations model after go-live, including any retainer terms.
- Client inputs and their due dates.
- One-time costs separated from recurring costs.
Also ask how a change request is priced and how a missed assumption would affect the fee.
Do the Jitsi and BigBlueButton apps require a specific Rocket.Chat plan?
Confirm the plan requirement for each app with the marketplace listing and Rocket.Chat's plans page before you choose a tier. This page does not confirm those requirements.
What is confirmed: Rocket.Chat's free Starter plan allows up to 50 users and includes LDAP and Active Directory authentication, single sign-on and multi-factor authentication. The free Community workspace allows up to 100 concurrent users with core messaging. Paid plans are priced by quote, multi-instance and microservice designs require a paid plan, and air-gapped deployment is a paid-plan capability. Ask your provider to confirm in writing which plan each app needs in your setup and which features your chosen authentication method depends on.
How DeployOpen scopes and delivers Rocket.Chat video call integrations
DeployOpen plans, builds and hands over self-hosted video calling for Rocket.Chat, using the Jitsi and BigBlueButton marketplace apps inside your own cloud accounts, data centers or air-gapped networks. Each engagement starts with a written, fixed scope that names the video platform, the Rocket.Chat plan, the hosting model and the handover deliverables before any build work begins.
How we scope
- Confirm which Rocket.Chat version and plan are in use, since marketplace app behavior depends on the supported release line.
- Decide between Jitsi, BigBlueButton or both, based on meeting size, recording needs and the hosting footprint you can operate.
- Record network requirements in the written scope, including public hostnames, certificates, and firewall rules for the required ports.
How we build
- Deploy the chosen video platform on servers or clusters you control, with its web, media and signaling components sized to expected concurrency.
- Install and configure the Rocket.Chat marketplace app, then test room creation, joining, screen sharing and audio from desktop and mobile clients.
- Set up authentication for video sessions, such as JWT tokens for Jitsi or the shared secret handling required by the BigBlueButton API.
How we hand over
- Deliver configuration records, network diagrams, port inventories and a test report that your team can check against the written scope.
- Document the operational runbook for certificate renewal, version upgrades, capacity changes and recording storage management.
- Walk your administrators through day-two tasks so they can change settings, add media capacity and read logs without outside help.
How we support
- Ongoing upgrades, monitoring and incident response for the video stack are available as a retainer, agreed in writing.
- Plan upgrades of Rocket.Chat and each video platform as separate changes, since each release line has its own support and install requirements.
- Ask for a quote built from the written scope, which states who maintains the servers, how often updates are applied and what is included.
