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 the WebTrit backend to the existing cloud PBX system to verify the login, extract the SIP settings (so the WebTrit backend can properly initiate a VoIP connection), etc. And, since every system has its 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 backend. 

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) that 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 the PBX of company XYZ, but assigned to totally different persons), each user has some unique identification for them to use 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). This way 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 simply passes the user ID, entered by the end user, to the API of the VoIP system for authentication.

In some situations, however, there are multiple physically separate PBX systems, e.g., each customer gets allocated a virtual machine with an Asterisk. (That may sound crazy, but our team once worked with a CSP that had over 2,000 such customers!)

In this case, Mary or Bob use their extension number (say, 101) as their login into the system. This 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 workable but extremely inefficient solution would be to run a separate instance of WebTrit for each individual customer (ABC, XYZ and others). It would then connect 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.

So, 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. Then WebTrit and API adapter identify the end user properly. 

When the app sends a request to the WebTrit backend 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. This is something that allows us to distinguish between two companies.

But, this requires extra decisions for the end user and additional work for application maintenance. 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 an “auto-configure your app” link.

When Bob or Mary click on that link on their smartphone, it opens the app. (Obviously, it has to be installed beforehand.) The correct settings are stored in the app, so 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 backend to use different adapters for different tenants! For instance, if we extend our example. Previously, we had an adapter connecting to individual Asterisk PBX. Now, the 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 two 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”, the WebTrit backend 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.) That 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.) And all with the same app that is already published in the store, so minimal effort is needed!