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.
Introduction:
WebTrit is a platform that allows for the rapid development and publication of white-label mobile and web applications for real-time communications. This post is about a common situation where the service provider or enterprise customer deploying WebTrit manages many different PBXes (public branch exchange, a legacy term for telephony business server these days), each serving different clients or offices. This kind of system is called “multitenant” in the telecommunications industry.
Multi-tenancy allows the use of a single published mobile app and a single instance of the WebTrit back-end to provide a service to many different users. These users can be serviced from different PBX systems (e.g., each corporate customer has their own 3CX or Asterisk box). Multi-tenancy also enables the operator to test a new version of an API adapter or connect to a new PBX system without disruption to the current set of users.
API Adapter – quick refresh
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.
You can find more details about the API adapter in this dedicated post.
The classic connection scheme – a single app, a WebTrit back-end and cloud PBX system
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.
Multiple VoIP PBX systems
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.
The wrong approach to the problem of multiple PBXes
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.
Multiple VoIP PBX systems – the right way
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!
Multiple tenants and multiple adapters
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!
Technical details – how to use multi-tenancy in your applications
Identifying the tenant in app <-> WebTrit back-end communication
When the app connects to the WebTrit back-end, if it wants to use a specific tenant ID, it simply adds /tenant/XYZ into the path of the API request. For example, to login user 101, which belongs to the tenant XYZ, the HTTP POST request is sent to https://demo.webtrit.com/tenant/XYZ/api/v1/session (as opposed to https://demo.webtrit.com/api/v1/session when we do not use tenants, so all users are considered to be under a single “default” tenant)
Identifying the tenant in WebTrit back-end <-> API adapter communication
When WebTrit back-end receives incoming requests from the client (app, web client, etc.) it checks whether a tenant ID is supplied in the URL path and if yes – then it consults the configuration for the mapping between tenant ID and the API adapter. If no matching ID is found in the list, then the adapter, associated with the default tenant, is used. Continuing with our example from above – let’s assume the configuration on the back-end side provides the following list of tenants and API adapters:
ABC – https://asterisk-adapter.aws.com
XYZ – https://asterisk-adapter.aws.com
Default – https://portaswitch-adapter.cloud.google.com
So now the inbound request to perform a user authentication (with username 101 and password supplied by the user) is sent to the adapter, associated with XYZ tenant – https://asterisk-adapter.aws.com/api/v1/session and a custom HTTP header X-WebTrit-Tenant-ID is added to that request with the value “XYZ”. Adapter extracts that value and uses it accordingly – in our case, connecting to the PBX of XYZ company and validating that the provided password is valid for extension 101 (Bob).
Summary
Multi-tenancy functionality allows an operator to configure multiple API adapters, connected to the same WebTrit instance. When the app (or web application) interacts with the WebTrit API and attempts to authenticate or perform other operations on behalf of the end user, it supplies an additional parameter called tenant ID. That parameter is used to choose a specific API adapter; and its value is also passed along with other information to the adapter.
So it is possible to have a single API adapter, connecting to multiple VoIP systems – for instance individual PBX boxes. This allows a telecom operator to use a single app, published in the Apple/Google app store under their own brand, and connected to a single WebTrit instance in conjunction with multiple PBX systems.
If you have questions, or would like to discuss your solution needs further, please contact us!