CONFIDENTIAL PROJECT

Multi-Tenant IP PBX & UCaaS Platform

A multi-tenant communication platform combining IP PBX infrastructure, SaaS administration, APIs, WebRTC, provisioning and business workflows.

FreeSWITCHAsteriskSIPWebRTCReactNext.jsNestJSPostgreSQL
Industry
UCaaS / hosted business phone
Type
Multi-tenant IP PBX + SaaS control plane
Role
Solution architecture + full-stack engineering
Platform
Shared SIP cores · isolated tenants · REST APIs
Stack
FreeSWITCH · Asterisk · NestJS · PostgreSQL · WebRTC
Proof
Documented full admin / frontend / API stack and multi-device support

The problem

Businesses needed a communication platform that could support multiple organizations from a shared deploy while keeping users, extensions, configuration and administration separate.

Constraints

Delivery stayed inside the client's stack, tenancy, compliance and media-ownership boundaries. Where a choice was forced (suite vs owned plane, BYOC vs CPaaS, local vs cloud models), the architecture section below records the trade-off rather than a marketing rewrite.

The challenge was not simply installing an IP PBX. Telephony infrastructure, frontend applications, backend APIs, database architecture and multi-tenant administration had to work as one system. A leaky tenant boundary is a product-ending bug — not a later ticket.

Constraints that actually mattered

  • Shared media ports and SIP trunks for cost and operations
  • Per-tenant extensions, devices, IVR and recordings
  • Administrators who must never see another company’s queue or CDR
  • Desk phones and browsers on the same numbering plan
  • Provision through APIs, not only XML edits on a core

Business requirements

One codebase that can sell seats to many companies. Each tenant gets its own users, devices, extensions and administrators. The media cores stay shared. The application owns identity, provision and the product surface.

The solution

Designed and built a multi-tenant IPPBX platform. The documented portfolio describes a full admin / frontend / API stack and multi-device support — not a FreeSWITCH box with a spreadsheet of extensions.

Asterisk and FreeSWITCH handled SIP and media. NestJS exposed provision, auth and CDR APIs. React and Next.js delivered tenant admin and a super-admin console. PostgreSQL stored tenant-scoped configuration. WebRTC covered browser endpoints so users did not need a desktop softphone for day-to-day calling.

Call control and media stay on the PBX cores. The application layer owns tenants, users, devices, billing hooks and APIs. Supervisors never see another tenant’s queue, recording or extension list.

How the system flows

Every API row carries tenant_id; provisioning pushes isolated config to FreeSWITCH and Asterisk cores under one control plane.

flowchart TD
  SA[Super-admin creates tenant] --> API[NestJS provision APIs]
  API --> PG[(PostgreSQL tenant_id on rows)]
  PG --> FS[FreeSWITCH directory routes]
  PG --> AST[Asterisk apps]
  CP[Customer portal users extensions] --> API
Tenant isolation — one product, many organisations.

Architecture

Administration and the customer portal sit above the same NestJS APIs. PostgreSQL holds tenant-scoped data. FreeSWITCH and Asterisk terminate SIP/RTP. WebRTC browsers and SIP devices share the numbering plan.

flowchart TB
  Admin[Administration super-admin trunks]
  Portal[Customer portal extensions IVR]
  API[NestJS auth provision CDR]
  PG[(PostgreSQL tenant scoped)]
  FS[FreeSWITCH media routing]
  AST[Asterisk SIP apps]
  SIP[SIP RTP carriers]
  Admin --> API
  Portal --> API
  API --> PG
  API --> FS
  API --> AST
  FS --> SIP
  AST --> SIP
Multi-tenant IP PBX architecture.

Key components

Telecom

FreeSWITCH and Asterisk cores, SIP registration, RTP, trunks and the device path.

Backend

NestJS APIs for auth, provision, CDR and workflow hooks — the PBX is not the product database.

Frontend

React / Next.js tenant admin and platform console. Multi-device: SIP + WebRTC.

Database

PostgreSQL as the system of record. Tenant scope on users, devices, numbers and recordings.

Engineering challenges

  • Multi-tenant architecture — shared media, isolated identity, CDRs and recordings.
  • PBX / application separation — the core owns calls; the app owns tenants and product rules.
  • SIP integration — registration, trunks and inbound DID mapping to tenant objects.
  • Multi-device calling — desk phones and browsers on one numbering plan.
  • Administration and provisioning — APIs instead of XML-only operations.
  • API / PBX coordination — a provision write must become a live registration path, not a stale file.

How those were solved

Tenant context is required on every SIP request, HTTP API and background job. Isolation is not a prefix in a shared context. The control plane writes configuration the cores consume; supervisors authenticate against the application, not against a shared FreeSWITCH XML directory.

WebRTC users are provisioned as first-class devices: credentials, ICE/TURN and the same extension object the SIP phone uses. That is the difference between “we also have a browser demo” and multi-device support on a hosted PBX.

My role

Solution architecture + full-stack engineering. Architecture, backend/API, frontend, PBX integration, database, multi-tenancy, system integration and production-oriented design. Confidential client names, DIDs and recordings stay off this page.

ArchitectureBackend / APIFrontendPBX integrationDatabaseMulti-tenancySystem integrationProduction design

Technology stack

FreeSWITCHAsteriskSIPWebRTCReactNext.jsNestJSPostgreSQLREST APIs

These technologies are the documented stack for this platform. This page does not add engines or frameworks that were not part of the work.

Production considerations

  • Tenant id on SIP auth, CDR, recording URLs and admin sessions — tested, not assumed.
  • Provision jobs must fail visibly if the core rejects config; no silent partial writes.
  • WebRTC ICE/TURN provisioned per tenant alongside desk phones.
  • Carrier and codec policy documented per deploy; rollback path for dialplan pushes.

Engineering outcomes

No invented conversion rates or uptime claims. What this system actually established:

  • Centralized PBX, application and administration into a multi-tenant platform.
  • Multiple organizations on one deploy, with device mix: SIP + WebRTC.
  • Admin and API layers instead of FreeSWITCH XML-only operations.
  • Telephony connected to the application, administration and SaaS layers — not treated as an isolated telecom server.

Screenshots and diagrams

Representative multi-tenant IP PBX administration dashboard
Product administration surface used on this site for the hosted PBX control plane.
Representative platform-admin dashboard for a multi-tenant FreeSWITCH and Asterisk SaaS PBX
Platform admin: tenants, trunks, provision jobs and isolation checks.
Tenant user and extension management screen for SIP and WebRTC devices
Tenant scope: users, extensions and DIDs — another organization never appears here.

Related recordings on this site (existing videos only): Linux IP PBX walkthrough and cloud IP PBX — IVR and ring groups.

Architectural insight

Instead of treating the PBX as an isolated telecom server, the platform connected telephony infrastructure with the application, administration and SaaS layers. That is the product. The cores are the voice plane inside it.

The same isolation rules are written up as architecture notes in How to Build a Multi-Tenant Cloud PBX and the production FusionPBX/FreeSWITCH build article. This case study is the shipped platform those articles describe.

FAQ — buyer & architecture questions

Ten common questions about this case study, fit, and engagement.

Organizations need shared voice infrastructure with isolated tenants, APIs and admin—not a single-company PBX spreadsheet.

Yes. That is the documented multi-device pattern in this portfolio.

No. This is a product you operate or resell—a control plane around FreeSWITCH/Asterisk.

Share tenant count, carriers and whether pain is isolation, provision or media. Use contact.

No. Confidential deployments use use-case titles; screenshots are from controlled environments.

See multi-tenant cloud PBX and related case studies.

Share the current stack (PBX, CRM, cloud), the failure or goal in one paragraph, peak call volume, carriers, and any deadline. Screenshots, a pcap, or a short Loom beat a 40-page RFP. Use the project brief or email hello@unifiedpbx.in.

Yes. Delivery is remote-first from Delhi with scheduled overlap for EU, UK, US and APAC stand-ups. Production changes use written runbooks, rollback steps and agreed maintenance windows.

Yes. Many engagements begin with a 1–2 week SIP trace review, tenant-isolation audit, or architecture assessment. If the fit is good, scope expands from evidence—not from a generic sales deck.

Founders, CTOs, telecom leads, MSPs and product teams building or fixing UCaaS, CCaaS, CRM+voice, AI voice, or vertical SaaS—not buyers who only need seats on a mass-market suite.

Building a hosted PBX or UCaaS control plane?

Share the tenant model, current cores and the provision gap. The first reply is whether the problem is isolation, SIP or the application layer.

Discuss Your Project