h1. Virtual PBX {{>toc}} *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. h2. 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 handler|Call handlers]]. To perform balance cutoff of a virtual PBX subscriber a [[Dealer|Dealer mode]] is used. h2. 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: !virtual_pbx_index.gif! Step-by-step instructions on configuring are located in section [[Configure virtual PBX]]. [[Виртуальная АТС|Русский перевод]]