WebTrit Multi-Tenancy: Manage Multiple PBX Systems with Ease

Are you juggling multiple PBX systems for different clients or offices?

Simplify your WebRTC development with WebTrit’s powerful multi-tenancy feature. Empower your users with a seamless experience across all systems, optimize processes, and unlock the flexibility to scale without limits.

The role of the API adapter is to connect WebTrit back-end to the existing Cloud PBX system to verify the login, extract the SIP settings (so WebTrit back-end can properly initiate a VoIP connection), etc. And since every system has their own API – by using a different API adapter you can connect WebTrit to a variety of VoIP systems without any changes to the “core” WebTrit back-end. 

In the most common scenario, when used by a telecom operator or CSP, there is a single large-scale Cloud PBX or Unified Communications system (such as PortaSwitch or BroadWorks), which hosts multiple customers, each of them residing in its own isolated PBX environment.

It means that although some configuration options may overlap (for example, extension 101 may exist in the PBX of company ABC as well as in PBX of company XYZ, but assigned to totally different persons), each user has some unique identification for him / her to login to the self-care portal (e.g., their email address or their mobile phone number) or for their phone to connect to the SIP server (which could be 101@abc vs. 101@xyz or something else), so the system always know exactly whether we are dealing with 101 from ABC or XYZ.

So the multi-tenancy is implemented on the cloud PBX side and WebTrit does not have to worry about it at all – it merely passes the user ID, entered by the end user, to the API of the VoIP system for authentication.

But in some situations there are multiple physically separate PBX systems, e.g., each customer gets allocated a virtual machine with an Asterisk (sounds crazy, but I worked with a CSP who had over 2,000 such customers!).

In this case Mary or Bob use their extension number 101 as their login into the system, which works fine since they go to the web UI of their PBX.  But WebTrit needs some way to determine whether we are working with extension 101 of Bob or Mary and connect to the correct PBX system.

A working, but extremely inefficient solution would be to run a separate instance of WebTrit for each individual customer (ABC, XYZ and others), which connects to a specific PBX instance. Besides the amount of computing resources it may require, this would also mean that CSP has to publish an individual app for ABC, XYZ, and every other company to the Apple/Google app markets – and that would be a LOT of administrative work!

So this is clearly impractical – we cannot recommend this approach to providers with more than a handful of clients on individual PBX boxes.

What can we do in order to use the same app, published in the app stores under one brand, and connected to a single WebTrit instance, but to allow it to connect to the correct PBX of Bob or Mary?

Clearly we need some additional identification, which will be related to ABC or XYZ, so then WebTrit and API adapter identify the end user properly. 

When the app sends a request to WebTrit back-end for user authentication or further operations, alongside the user ID (101 in our example) it also sends an additional parameter called “Tenant ID” (in our example it would be ABC or XYZ). This parameter is then passed to the adapter, which uses it to determine which specific PBX instance it connects to.

Since we want the single app published in the app store to be used by both Bob and Mary, we cannot pre-configure the tenant ID value in the app. The most straightforward option is that the value for tenant ID attribute has to be populated via a custom login page in the app, so the user, in addition to entering their user ID (101) also types their corporate web address, picks a company from the list, etc,. – something that allows us to distinguish between two companies.

This requires extra decisions for the end user and additional work for application maintenance, so a much better alternative is to supply the tenant ID to the app (alongside user-specific information) via an auto-configuration link. So an admin creates an account for Bob or Mary and sends them a welcome email, which contains a “Auto-configure your app” link.

When Bob or Mary click on that link on their smartphone, it opens the app (obviously has to be installed beforehand) and the correct settings are stored in the app. Voila! They can start making calls without having to worry about the login info at all!

It is also entirely possible for a single WebTrit back-end to use different adapters for different tenants! For instance if we extend our example – previously we had an adapter connecting to individual Asterisk PBX, but now telco has also installed a new powerful UCaaS system and is slowly moving customers there (By the way, this is based on a true story of that operator with 2 thousand Asterisk boxes and their migration to PortaSwitch!). 

So now when the app tries to login to a user with tenant ID “ABC” or “XYZ”, WebTrit back-end sends a request to the previously discussed adapter for Asterisk. For  other tenant IDs ( we can have a “default” one for any tenant ID not explicitly listed) the request goes to an entirely different adapter (in our example this would be the one for PortaSwitch, based on our open-source project for API adapter written in Python), which enables the connection to PortaSwitch.

The same approach can be used to test a new version of the adapter or VoIP system (for instance you are preparing to update your VoIP platform to a new version and have a “staging” installation with the new release running in parallel to the old one) with the same app that is already published in the store, so there are minimum efforts!