Virtual PBX¶

• Table of contents
• Virtual PBX
  • Features
  • Configuration sequence

Virtual PBX (or Hosted PBX) — is a service for companies, which replaces physical office PBX and even a call center.
The root of service is that a customer (company) gets into full usage IP-PBX, which is physically located at provider's site (here from a definition virtual comes).

The virtual PBX service may be provided by ISP, ITSP, or telco.

Features¶

Virtual PBX provides all standard features of IP-PBX:

• multi-channel DID number
• Call recording
• IVR
• Call transfer
• Call forwarding

And additionally

• call-center
• CRM system
• etc (see section VAS)

All this is available to customer through the Internet without purchasing equipment.

Historically there exist 2 methods of implementation of virtual PBX service on provider's side:

• installation of VDS (Virtual Dedicated Server) for each subscriber on one (or several) physical server, and then installation of standard single-user PBX on each VDS.
• installation of PBX software which supports multitenancy on 1 physical server. Thus, subscribers don't see each other. Meanwhile, some part of configuration might be shared by all subscribers, for example, information about billing packs and available route sets.

1st method is simpler to deploy for a small set of virtual PBXs, however when the number of PBXss increases some problems may arrive:

• difficulties with software updates. Have to update each VDS individually.
• issues with performance. VDS works slower than physical server. The greater is the amount of launched VDS's, the less will be the performance of each of them
• difficulties with routing. You'll need one more physical server, or VDS, which will accumulate traffic from virtual PBX's and spread it to available telephony providers. And also to route incoming calls to DID numbers to corresponding VDS. If this routing server is deployed as VDS on the same server - then each call actually will come twice through the same physical server (through VDS of client and through routing VDS), dividing server's throughput twice. If routing VDS is a separate server - you'll need to spend money for its maintenance.
• difficult to maintain shared elements of web-interface - billing packs, typical IVR examples, available set of routes, etc.
• difficulty with unified working on a system. For example, billing and call limitation should be done on routing server, and subscriber's web account for PBX management is located on his virtual server and therefore when entering he doesn't see neither his balance nor his prices which have been assigned to him, nor billing per each call. To see this information provider should allocate a separate web-account to subscriber on his routing server which complicates working with system.

The 2nd method of implementation is more difficult to implement in software, but doesn't have issues described above.
However to implement this method it's mandatory to perform well-designed system of delimited multitenant access to web-interface of a system and a way to specify what is allowed to see a subscriber and what's not.

For Smartswitch we chose the 2nd way of implementation of virtual PBX as we believe it has more perspectives.
To delimit access rights for virtual PBX subscribers a Role-based access is used.
Therefore subscribers don't see each other.
At the same time, part of configuration could be shared between all subscribers, for example, billing packs information and available set of routes as well as standard Call handlers.
To perform balance cutoff of a virtual PBX subscriber a Dealer mode is used.

Configuration sequence¶

The sequence of adding new users is as follows:

• A Smartswitch administrator adds a new user group with a role of Virtual PBX administrator and assigns Billing pack and Route class to it.
• The Smartswitch administrator add a new Virtual PBX administrator in this user group.
  This could be done either through User generation by administrator and producing scratch cards.
  Or generation could be done thought your company web-site through ICE API.
  Or administrator could add new users one by one manually when they sign new contracts.
• A Virtual PBX administrator enters his personal web-cabinet and adds new PBX users and assigns internal extensions to them.

After this PBX users could dial each other.
Also they can call to external numbers according to Billing pack and Route class, which has been assigned to a Virtual PBX administrator.
Their calls are limited by a balance of Virtual PBX administrator (The same Balance cutoff options are available as for regular users).
Virtual PBX administrator can't change his billing and routing settings, which have been assigned to him by Smartswitch administrator.
Invoicing for Virtual PBX administrator is performed the same way as for regular users.
To refill Virtual PBX administrator could use the same methods which are available to the regular user (using scratch cards, through the company's site connected with ICE API, via bank wire, or using any of Payment systems).

The web cabinet of Virtual PBX administrator is very limited in functionality when compared with Smartswitch administrator web cabinet and allows to perform only defined actions.
The default look of web cabinet:

Step-by-step instructions on configuring are located in section Configuring virtual PBX.

Русский перевод