Skype for Business conferencing alternative

Open-source alternative to Skype for Business conferencing: the short answer

If your renewal, licensing change or data residency requirement touches the conferencing side of Skype for Business Server, the self-hosted replacements are Jitsi Meet and BigBlueButton, both run on servers in your own data center or cloud accounts for audio, video and web conferencing with desktop sharing. Jitsi Meet is the general purpose choice for ad hoc and recurring meetings, while BigBlueButton is built around virtual classrooms and structured sessions with slides, polling, a shared whiteboard and breakout rooms. Neither is a drop-in copy of the Skype for Business meeting client, so the decision starts with the kinds of meetings your staff hold most often.

Chat, presence and persistent group messaging are a separate module, covered elsewhere in this content group, so this section only addresses meetings. The choice between the two conferencing tools depends on meeting type, host count and whether you need recording. Jitsi Meet is licensed under Apache 2.0 and its Docker setup separates web, Prosody, Jicofo, Jitsi Videobridge and optional Jigasi (SIP gateway) containers, which suits scheduled and impromptu calls. BigBlueButton is licensed under LGPL-3.0 and asks for a dedicated server with at least 16 GB of RAM, 8 CPU cores and a clean Ubuntu 24.04 installation, which suits longer sessions with presenters. Confirm with your architects which SIP dial-in and Outlook invite requirements apply before you choose, because the details below depend on that answer.

How Skype for Business conferencing features map to Jitsi and BigBlueButton

This table maps the conferencing capabilities that a Skype for Business Server Enterprise CAL typically covers to Jitsi Meet and BigBlueButton. Read each row as a starting point: where a cell says partial or add-on, the gap needs a design decision, and feature parity should be confirmed against the current release notes of each platform before you commit.

Capability	Jitsi Meet	BigBlueButton
Audio and video conferencing	Core function. Web app served by nginx or Apache, with Prosody, Jicofo and Videobridge handling media. Confirm browser and mobile client behavior in your environment.	Core function for classes and meetings, with audio, video, chat and slides. Built for virtual classrooms, so confirm fit for large corporate all-hands sessions.
Desktop and application sharing	Screen sharing is supported in the web client. Confirm per-application sharing and client-specific behavior for your operating systems.	Screen sharing is supported. Confirm whether individual window sharing and sharing from mobile devices meet your needs.
Dial-in by phone (PSTN and SIP)	Partial. Requires the Jigasi SIP gateway in the Docker or manual deployment, plus a SIP trunk or PBX from your telephony provider. Dial-in numbers and PIN handling must be designed and tested.	Partial. Phone dial-in is not a standard built-in path in the same way. Confirm with the project and your telephony provider whether a SIP bridge is needed.
Recording and streaming	Add-on. Jibri handles recording and streaming as separate components, with their own host sizing and storage. Confirm the current Jibri setup for your release.	Built in. Recordings are stored on the server, so disk sizing must account for them. The install docs list 500 GB for recordings and 50 GB without recording for a 4.0 server.
Breakout rooms	Not a standard built-in feature in the same form. Confirm current support or plan an alternative workflow such as separate rooms.	Built in. Breakout rooms are part of the core feature set. Confirm behavior with your chosen release.
Whiteboard and polls	Partial. Whiteboard and polling depend on the client features and any add-on tools you integrate. Confirm availability in your release.	Built in. Multi-user whiteboard, polling and shared notes are part of the feature set, alongside slides with annotations.
User authentication and room access	Internal XMPP accounts, JWT tokens, LDAP and Matrix verification are configured through the .env file. JWT is the recommended method, with a separate anonymous domain for guests.	Greenlight v3 supports external login through OpenID Connect. Keycloak is suggested to add Microsoft, SAML and other methods. API calls require checksums using a shared secret that must never be exposed in a web page.
Calendar invites and meeting links	Meeting links are plain room URLs that you place in Outlook invites through your own process or a plugin. Confirm the integration path for your mail system.	Meeting rooms are created through Greenlight or the API. Outlook invites need a link or integration built for your environment. Confirm the approach with your team.

Jitsi Meet or BigBlueButton: when each fits

Jitsi Meet and BigBlueButton both run on your own servers and cover the audio, video and screen sharing that Skype for Business meetings provided. They differ in weight, in the features they add and in how much infrastructure they expect. The cards below set out which one fits which requirement and what to confirm before choosing.

Jitsi Meet for ad hoc meetings

Jitsi Meet is an Apache 2.0 video conferencing project that fits the common Skype for Business case: quick browser-based meetings with desktop sharing. A self-hosted install is built from Prosody (XMPP), Jicofo (the conference focus), one or more Jitsi Videobridge media routers and the web server. You can deploy it from Debian or Ubuntu packages or from the official Docker setup. Confirm that your clients need only a browser and that your team is comfortable operating a multi-component service.

Jigasi for SIP dial-in

Jigasi is the SIP gateway in the Jitsi stack. It lets callers join a Jitsi meeting by phone, which is the closest equivalent to the dial-in bridge many Skype for Business estates used. Jigasi runs as its own component, so it needs a SIP trunk or PBX that you already operate or contract separately. Ask your telephony team which SIP provider will carry calls, how dial-in numbers and PINs will be issued, and who supports the trunk.

Jitsi scaling and capacity

Jitsi scales by adding videobridges, and the default install is already set up for horizontal scaling. 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. Each bridge needs UDP port 10000 reachable from participants. Plan capacity from your peak concurrent participants, not from total headcount, and test with your own traffic before sizing.

BigBlueButton for structured sessions

BigBlueButton is an LGPL-3.0 virtual classroom maintained by BigBlueButton Inc. It adds slides with annotations, a multi-user whiteboard, shared notes, polling, recording and breakout rooms, which suit training, webinars and town-hall style sessions better than ad hoc calls. It is heavier to run than Jitsi. Confirm that you need these presenter features, because they are the main reason to accept the extra server load.

BigBlueButton server requirements

A BigBlueButton 4.0 server needs at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, and 250 Mbit/s symmetrical bandwidth. Recording needs 500 GB of disk, or 50 GB without it. The server needs TCP 80 and 443 and UDP 16384 to 32768 open, a valid hostname for SSL, and Docker for document conversion. Direct upgrades from 2.6, 2.7 or 3.0 are not supported, so plan a clean installation on Ubuntu 24.04.

Jitsi as a Service from 8x8

8x8 runs Jitsi as a hosted service (JaaS), and the free public instance is meet.jit.si. This option removes the servers, the upgrades and the on-call work, but meetings, recordings and account data run on 8x8's infrastructure. It does not meet a requirement that conferencing media and metadata stay in your own data center or air-gapped network. Choose it only when a hosted service is acceptable under your data residency and audit rules, and confirm those terms in writing.

What each Jitsi component does and which ports it needs

A self-hosted Jitsi Meet deployment is several services working together, and the reader needs to know which one fails when a meeting misbehaves. The nginx or Apache web server serves the browser app. The Prosody XMPP server handles signaling and user accounts for the conference. Jicofo, the conference focus, creates conference rooms and decides which Videobridge should carry each participant's media. The Jitsi Videobridge (JVB) routers carry the actual audio and video streams. The official Docker setup separates these roles into web, prosody, jicofo and jvb containers, and adds jigasi for SIP dial-in and jibri for recording and streaming. Confirm which of these you need before you size the host, because Jigasi and Jibri add their own resource and network requirements.

The videobridge tier is the part that scales horizontally. Media is the heaviest load in a meeting, so the Jitsi scalable setup guide's approach is to add more Videobridge instances rather than enlarge one machine. The 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 notes that the default install is already configured for horizontal scaling. Those sizes are the handbook's starting points, not a capacity guarantee, so load test with your own meeting sizes and bandwidth before you commit to a count.

The Debian 12 or newer and Ubuntu 24.04 or newer quick start needs ports 80/TCP and 443/TCP open for the web app and certificate handling, and 10000/UDP for media. Port 5349/TCP is the TCP fallback for clients whose networks block UDP, and 3478/UDP for STUN is optional. Check these rules at the firewall and at any cloud security group, not only on the host. A valid domain certificate also matters: the handbook says HTTPS with a proper certificate is necessary for working audio and video, and it warns that self-signed certificates cause problems, especially with mobile clients. Plan for a public DNS name and a certificate from a trusted authority, and test from outside your network before users rely on the service.

Which tool to deploy for which meeting pattern

Ad hoc internal meetings are short, unscheduled calls between employees who already have directory accounts. Jitsi Meet fits this pattern best, because a room opens in a browser with no recording, breakout or classroom tooling to configure, and the self-hosted deployment keeps audio, video and room names inside your network.

Server footprint: The Debian and Ubuntu quick start asks for ports 80/TCP, 443/TCP and 10000/UDP, a supported OS (Debian 12 or newer, or Ubuntu 24.04 or newer) and OpenJDK 17. The scalable guide suggests a 4 CPU, 8 GB machine for the central server.
Authentication model: Use JWT token authentication, configured through the .env file in the Docker setup, so that only users your identity system issues tokens for can create rooms. The older secure domain method is deprecated for new installations.
Directory integration: The Docker guide also lists LDAP as an option, which can align room access with existing accounts. Confirm the exact settings for your directory with the current handbook.
Certificates: A valid certificate for the domain is required for working audio and video, so plan a proper hostname before rollout.
Scaling: Add videobridges horizontally if concurrent calls grow, since the default install is already set up for it.

Check that your identity provider can issue the JWT claims Jitsi expects before you promise employees a self-service room link.

How SIP dial-in and Outlook meeting links work in practice

Jigasi is the SIP gateway in the Jitsi Docker setup, and it is the component that lets a phone caller join a Jitsi conference. It runs as its own container next to web, prosody, jicofo, jvb and jibri, so it can be sized and restarted without touching the video path. Jigasi does not supply telephone numbers or carrier connectivity. You need a SIP trunk or hosted telephony provider that your organization already holds or buys separately, and that provider must route inbound calls to your Jigasi endpoint. Before scoping the work, confirm with your telephony team whether existing trunks can point at the new server, which dial-in numbers you will publish, how PIN handling will work, and whether your chosen Jitsi release documents the Jigasi settings you need. Those settings are applied through the .env file in the Docker setup.

Meeting links reach Outlook invites in one of two ways. The simplest is a fixed invite template that your IT team maintains, containing the room URL pattern, the dial-in numbers and a short join explanation. Users paste this into their Outlook invitations, or an Outlook add-in or calendar connector is used if one is available for your Jitsi version. Room URLs should be generated consistently, and if you enable JWT token authentication, meeting access depends on tokens your identity system issues, so the invite process must match that design. Test the flow end to end with a sample invite from Outlook on desktop, web and mobile, and confirm the join experience for external guests. Confirm with your Jitsi build, and any third-party add-in you consider, what calendar integration exists and whether it is maintained, because support for Outlook and dial-in numbers varies by version and should not be assumed.

Running Jitsi or BigBlueButton beside Active Directory, Exchange and existing chat

Jitsi or BigBlueButton does not run on its own. Identity, calendar invites, network paths and the chat platform you keep during the transition each need an owner before the first meeting is scheduled. The cards below name the dependency, the decision it forces and the question to put to your identity and network teams.

Choosing the Jitsi login method

Jitsi Meet can authenticate with internal XMPP accounts, JWT tokens, LDAP, Matrix user verification or a hybrid Matrix plus JWT mode, all set in the .env file of the Docker setup. The JWT option is the one the Jitsi handbook recommends, because the handbook marks the older secure domain method as deprecated for new installations. Ask your identity team whether directory accounts must be verified directly through LDAP or whether a token issued by your own application is acceptable, and confirm whether guests will use a separate anonymous domain.

Greenlight sign-in through OpenID Connect

BigBlueButton's Greenlight v3 front end supports external authentication through OpenID Connect, configured with environment variables. The Greenlight documentation suggests Keycloak as a broker so that Active Directory, Microsoft, SAML and other login methods can sit behind one standard login. Confirm with the identity team which directory groups may create rooms, and whether a Keycloak instance already exists or must be added to the scope.

Outlook invites carrying meeting links

Neither Jitsi nor BigBlueButton creates Outlook calendar entries on its own, so the meeting link has to reach invitees through a calendar integration, a scheduling form or a template your team maintains. Decide which mailbox or service account sends the invite, who owns the room naming scheme and how recurring meetings are handled. Confirm with the Exchange team how external invitees will open the link, since meeting access is only as strong as the room settings you choose.

Firewall and reverse proxy coordination

Jitsi needs ports 80/TCP, 443/TCP and 10000/UDP open, with 5349/TCP for TCP fallback. BigBlueButton needs TCP 80 and 443 and UDP 16384 to 32768 reachable, a valid hostname for SSL and a TURN server for users behind restrictive firewalls. Your network team should confirm which of these pass the perimeter, whether a reverse proxy terminates TLS, and whether the media ports can be opened from the user networks you serve. Self-signed certificates cause audio and video problems, so the certificate plan belongs in this review.

Keeping chat on the current platform

Conferencing can move before chat does. If the team keeps Teams, Slack or another chat tool during the transition, meeting links will be posted into a system that is not yet the home of the discussion. Agree with the collaboration owners which channel carries the link, how long the old chat remains the record and where Exchange-based recurring invites are kept. Teams Export APIs require an active Teams license on the users being exported, so confirm with the Microsoft 365 administrator that the license stays in place until the history is exported.

Sizing and ownership of the media servers

A BigBlueButton 4.0 server needs at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance and 250 Mbit/s symmetrical bandwidth, and 500 GB of disk if recordings are kept. Jitsi scales by adding videobridges. Ask the infrastructure team who patches the servers, where recordings are stored under your retention rules, and who owns the bandwidth contract, since these costs recur after the initial build.

Moving meeting habits and links off Skype for Business

This sequence moves recurring meetings, dial-in access and invite links from the Skype for Business meeting path to a self-hosted video platform that your team operates and that works from Outlook invites. It ends with a tested platform, updated templates and a retired legacy path.

Inventory meeting types and dial-in usage
Pull a list of the meeting patterns your organization uses on Skype for Business: scheduled internal meetings, external guest meetings, webinars, recurring team calls and dial-in participants who join by phone. Ask your Skype for Business administrators which meetings use the Enterprise Voice dial-in numbers, which rooms use conferencing devices and which meetings are recorded. Record the owner, approximate participant count and whether each pattern needs guests from outside your domain. The output is a short table that maps each pattern to its requirements, which becomes the input for platform selection.
Choose the platform for each pattern
Match each meeting pattern to a platform. Jitsi Meet suits browser-based meetings with guests and desktop sharing, and it can add SIP dial-in through its Jigasi gateway when your telephony team can provide a SIP trunk. BigBlueButton suits sessions that need a whiteboard, polling, breakout rooms or shared notes, and it is the stronger fit for training and webinar-style use. Confirm with your telephony and room system vendors whether they support the chosen SIP or meeting protocol, because those integrations are not automatic. The output is a signed-off mapping from each pattern to one platform, with the telephony gaps listed separately.
Build a clean server for the chosen platform
Provision a dedicated host or virtual machine inside your own infrastructure for each platform you selected. For BigBlueButton 4.0, plan a clean installation on Ubuntu 24.04 64-bit, because direct upgrades from 2.6, 2.7 or 3.0 are not supported. Size the server against the published requirements: at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, disk sized for recordings, and 250 Mbit/s symmetrical bandwidth. For Jitsi Meet, follow the Debian or Ubuntu quick start and open ports 80/TCP, 443/TCP and 10000/UDP. The output is a server that passes a basic connectivity check from both the internal network and an external test client.
Configure TLS and authentication
Issue a certificate for a proper domain name and configure HTTPS before any user testing, because the Jitsi handbook states that HTTPS with a valid certificate is necessary for working audio and video, and self-signed certificates cause problems, especially on mobile clients. For Jitsi, choose JWT token authentication for members and a separate anonymous domain for guests, rather than the deprecated secure domain method. For BigBlueButton, set up Greenlight with OpenID Connect against your identity provider, and confirm that your API integrations sign calls with the shared secret stored on the server side only. The output is a test in which an internal user signs in with corporate credentials and a guest joins a room without an account.
Pilot with one group
Choose one team whose meetings are representative, such as a recurring project group with both internal and external attendees. Run its normal meetings on the new platform for a defined trial period agreed with the team lead, and collect feedback on audio quality, screen sharing, dial-in behavior and recording. Test the scenarios that often fail: a participant on a restrictive network, a guest on a mobile browser and a participant who joins by phone. Log every issue and its resolution. The output is a pilot report that states which patterns pass, which need changes and whether the TURN or firewall configuration needs work.
Update invite templates and Outlook links
Replace the Skype for Business meeting join block in Outlook and calendar templates with the new meeting link, dial-in information and passcode guidance. Coordinate with the Exchange or Microsoft 365 administrators so that any transport rules, room mailbox settings or calendar add-ins that inject Skype links are reviewed and removed or updated. Publish a short join guide for users and for external guests. The output is a set of invite templates that a test calendar event produces correctly for internal and external recipients, with no leftover Skype join text.
Plan where existing recordings and meeting content go
Skype for Business meeting content and recordings are not moved automatically by this sequence, so decide where existing material will live before you retire the old path. Identify which recordings, shared files and meeting notes must be kept for business or compliance reasons, and export or archive them to storage your organization controls. Confirm retention obligations with your legal and records teams, and record where each category of content is stored. The output is an inventory of retained content with its storage location and owner, so no recording is lost during the cutover.
Retire the Skype for Business meeting path
Once the pilot passes and the invite templates are live, announce a cutover date to all users and turn off the Skype for Business meeting scheduling path for the migrated patterns, including the conferencing dial-in numbers you no longer need. Keep the old environment available for read-only access to archived material until your retention plan allows its removal. Review the new platform's logs and support queue for two weeks after cutover. The output is a confirmed list of disabled meeting paths, a documented fallback and a support record that shows no unresolved join failures.

Skype for Business conferencing alternative cost, effort and skills

What drives the cost of self-hosting Jitsi or BigBlueButton?

The main cost drivers are server hardware or cloud instances, bandwidth, TURN relay capacity, optional SIP telephony, and the staff time to build, run and upgrade the stack. Hardware and bandwidth recur monthly or yearly, while setup work is largely one-time. Scale matters most: Jitsi scales horizontally by adding videobridges, so media capacity grows with the number of bridges. BigBlueButton 4.0 expects a single larger server, with 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, according to the BigBlueButton install docs. 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. Confirm current sizing with the vendor before you budget, because these figures change between releases. Ask any quote to itemize servers, bandwidth, TURN, SIP and staff effort separately.

How long does a self-hosted Jitsi or BigBlueButton deployment take?

Duration depends on scope: a single-server Jitsi Meet install is the smallest job, while a scaled Jitsi cluster, a BigBlueButton server with Greenlight or LTI, SSO integration and SIP dial-in add steps and testing. No public duration is fixed here, so ask the partner for a timeline tied to a written scope. The work that most often extends schedules is DNS and a valid certificate, because the Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video. Firewall and port changes also take time: Jitsi needs 80/TCP, 443/TCP and 10000/UDP, while BigBlueButton needs 80 and 443 TCP plus UDP 16384 to 32768. Authentication design, such as JWT tokens or Keycloak in front of Greenlight, adds decisions that need stakeholder sign-off.

What must our internal team supply for a conferencing deployment?

Your team supplies the environment and the decisions, even when a partner does the build. You need a server or cloud account in your own infrastructure, a DNS name you control for the certificate, firewall rules that allow the listed ports, and an identity source for user login, such as your directory or an OpenID Connect provider. You also need someone who owns the Outlook integration, meaning how meeting links are generated and who may create rooms. For SIP dial-in through Jigasi, you need a telephony trunk and dial plan from your telephony provider. Plan for on-call ownership, patch windows and backups. Ask a partner to confirm which of these inputs they expect from you in writing.

Can our own engineers deploy Jitsi or BigBlueButton without a partner?

Yes, a capable Linux operations team can deploy both platforms using the official guides, and the Docker setup for Jitsi runs separate web, prosody, jicofo, jvb and jigasi containers. The harder parts are operational rather than installation: certificate renewal, scaling videobridges, TURN for users behind restrictive firewalls, SIP integration, authentication with JWT or LDAP, and keeping BigBlueButton current, since a 4.0 direct upgrade from 2.6, 2.7 or 3.0 is not supported. If your team has no one who has run real-time media before, a fixed-scope partner engagement can cover build, hardening and handover. Decide early whether you need a one-time build, a retainer for upgrades and support, or both.

What should we ask a partner for in a fixed-scope quote?

A fixed-scope quote should list each deliverable and the assumptions behind it. Ask for these items in writing:

Platform choice and reasons, with Jitsi or BigBlueButton sized to your expected concurrent meetings
Server, bandwidth and TURN specification, with the vendor sizing figures the partner relied on
SSO or LDAP integration, and the Outlook invite method
SIP dial-in scope, including which telephony trunk is in scope
Hardening, backup, documentation and handover acceptance criteria
Post-launch support or retainer terms, and what happens to upgrades

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your infrastructure, and works from a written scope before any work starts. It does not publish a price list, so a quote follows from that scope.

Which sizing and port figures should we confirm with the vendor?

Confirm every figure against the current vendor documentation for the release you will deploy, because versions change. For BigBlueButton 4.0, confirm the minimum RAM, CPU, disk and bandwidth figures in the install docs, and confirm the ports TCP 80 and 443 and UDP 16384 to 32768 for your firewall. For Jitsi, confirm the Debian 12 or Ubuntu 24.04 support, OpenJDK 17, the 80/TCP, 443/TCP and 10000/UDP ports, and the optional 5349/TCP and 3478/UDP. Also confirm the videobridge sizing in the scalable setup guide against your expected concurrency. Ask the partner to show where each figure came from.

Does self-hosting remove the need for telephony and room systems?

No. Self-hosting covers the meeting service itself, but dial-in and room hardware are separate components. Jitsi offers SIP dial-in through Jigasi, which requires a SIP trunk or PBX from your telephony provider, so budget for that line item and its recurring charges. BigBlueButton does not offer the same SIP gateway in the supplied facts, so confirm telephony options with the vendor before choosing it for dial-in. Room video systems and their licenses also sit outside the conferencing stack. Ask the partner to state which telephony and room components are in scope and which stay with you.

How DeployOpen scopes, delivers and supports a conferencing replacement

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For conferencing, that means a written scope covering the Jitsi Meet or BigBlueButton deployment, its identity and calendar integration, and the operating runbooks your team inherits.

How we scope

Inventory which Skype for Business conferencing features your users depend on, such as dial-in, desktop sharing and recording.
Confirm the target hosting location, network path, certificate domain and whether SIP dial-in through Jigasi is required.
Agree deliverables, timelines and exclusions in writing before work starts, since most engagements are fixed-scope.

How we build

Deploy the chosen stack on your servers, covering the web app, Prosody, Jicofo and Jitsi Videobridge, or the BigBlueButton server components.
Configure authentication, such as JWT tokens or OpenID Connect, and test meeting links from Outlook invites with real participants.
Run security testing of the deployment and document the configuration and the evidence needed for your compliance assessment.

How we hand over

Deliver architecture records, configuration files, operating procedures and a list of open decisions for your team to review.
Walk your administrators through certificate renewal, bridge scaling, backups and upgrade steps on your own infrastructure.
Confirm with your auditors or certification bodies which controls and evidence they will assess, since DeployOpen does not issue attestations.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped separately in writing.
Plan upgrades around the release branch you choose, and confirm the upgrade path for your version before each change.
Ask any quote to show who is paid for hardware, licenses, staff time and ongoing operations, so recurring costs stay visible.

Open-source alternative to Skype for Business conferencing