Hi I came across couple of pointers on the Internet regarding solutions available for providing hosted PBX service. 1. Multiple PBXs: Using separate hardware to host each PBX. Pretty straightforward, but no hosting company wants to use it. 2. Multi-tenant PBX: Configuring multiple PBXs within the same instance of Asterisk. I.e. partitioning a single instance of Asterisk into multiple PBXs by way of configurations, using unique landing context for each tenant. 3. Virtual PBX: Multiple virtual machines within the same hardware, each host an instance of Asterisk. Which one of the method above is generally used by hosted PBX service providers? Isn't the second option with ARA a good choice for dynamic creation of multiple "small" PBX tenants? Is the last option alone or combination of options 2 and 3 good for cloud based hosted PBX service offering? Thanks, Kannan. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120730/ae528c90/attachment.htm>
2012/7/30 Kannan <vasdeveloper at gmail.com>> Hi > > I came across couple of pointers on the Internet regarding solutions > available for providing hosted PBX service. > > 1. Multiple PBXs: Using separate hardware to host each PBX. Pretty > straightforward, but no hosting company wants to use it. > 2. Multi-tenant PBX: Configuring multiple PBXs within the same instance of > Asterisk. I.e. partitioning a single instance of Asterisk into multiple > PBXs by way of configurations, using unique landing context for each tenant. > 3. Virtual PBX: Multiple virtual machines within the same hardware, each > host an instance of Asterisk. > > Which one of the method above is generally used by hosted PBX service > providers? > > Isn't the second option with ARA a good choice for dynamic creation of > multiple "small" PBX tenants? > > Is the last option alone or combination of options 2 and 3 good for cloud > based hosted PBX service offering? > > Thanks, > Kannan. >Working in the voip field from a lots of years, I have found all three type of business. The first is maybe the easier and most common. Hardware is cheap and it is easier to "sell" a service like the PBX if it is sold together with a piece of iron. Usually the hardware is placed on client's network, using the bandwidth of the client. Usually together with the PBX is sold also a router/firewall/traffic shaper/vpn endpoint to try to optimize the traffic on the client's DSL. The major pros about this solution is you can use a normal PBX like freepbx/trixbox, the client can mess the config how he likes, without disrupting other services, you can install VoIP card to connect landlines,. The major cons is the cost of the hardware, the cost of the g.729 licenses (if any) and the maintenance cost of replacing hardware failures and the need to be physically near each client. The second is the holy grail of the VoIP providers. The major pros is the cost. Having a single hardware is cheap and it is still cheap also if you decide to get two to be ready in case of an hardware failure. The major cons is the software. You cannot use the award winning freepbx/trixbox family and you need to deal with sometime limited or incomplete developed interfaces. The client always asks for the missing feature. One other major cons is the "reload". If the PBX software is not made using ARA, then every time you add a new peer or a new DID, you need to reload the entire PBX and that is a resource killer. Again, if the pbx interface is not made using ARA, then you cannot let your clients to change the configuration or they will trigger continuous reload (and delaying reload for example every 10 minutes is not a solution) The last one is sometime the chosen compromise, but from my point of view, pbxes are not good software to virtualize. They are too sensible to delays and your voice quality can go down if the real server is overloaded. The same for the cloud based solutions (I have yet to found). I suspect the "cloud" is good for services like http, not for real time applications. Leandro -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120730/3f6fd42f/attachment.htm>
On Mon, Jul 30, 2012 at 2:36 AM, Kannan <vasdeveloper at gmail.com> wrote:> 2. Multi-tenant PBX: Configuring multiple PBXs within the same instance of > Asterisk. I.e. partitioning a single instance of Asterisk into multiple > PBXs by way of configurations, using unique landing context for each tenant. > 3. Virtual PBX: Multiple virtual machines within the same hardware, each > host an instance of Asterisk. >We use number two. We dabbled with number three but didn't like the results for a lot of different reasons. As others have mentioned, there is a certain level of danger when you mix companies so closely. We have in the past made a mistake and brought down the whole system, but it's been many years since we've done that. Part is improved skill and part is that Asterisk has improved and no longer commits suicide for certain minor errors. To do this, you need to plan out a good naming convention for everything that will be unique to customers accounts. SIP accounts, macros, contexts, etc etc. We use the accountcode feature and prepend the accountcode through the dial plan and accounts. accountcode.301 would be a SIP account accountcode#function would be a context name We do deploy custom hardware for specific functions or customers who are particularly large in some cases. We just need a good reason to. Like they want to self-manage, or they make a lot of changes, need custom integration with databases, etc. -- Carlos Alvarez TelEvolve 602-889-3003 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120730/f17b21b5/attachment.htm>
On Mon, 2012-07-30 at 15:06 +0530, Kannan wrote:> Hi > > > I came across couple of pointers on the Internet regarding solutions > available for providing hosted PBX service. > > > 1. Multiple PBXs: Using separate hardware to host each PBX. Pretty > straightforward, but no hosting company wants to use it. > 2. Multi-tenant PBX: Configuring multiple PBXs within the same > instance of Asterisk. I.e. partitioning a single instance of Asterisk > into multiple PBXs by way of configurations, using unique landing > context for each tenant. > 3. Virtual PBX: Multiple virtual machines within the same hardware, > each host an instance of Asterisk. > > > Which one of the method above is generally used by hosted PBX service > providers? > > > Isn't the second option with ARA a good choice for dynamic creation of > multiple "small" PBX tenants? > > > Is the last option alone or combination of options 2 and 3 good for > cloud based hosted PBX service offering? >We use 2 and I'd have to agree with most of what the previous replies have said. You really need to nail down your conventions and stick to them. We did this by creating our own custom front end so our conventions are built in to the front end code. ARA is really useful for this type of thing. If you're expanding to the point that you need to add new servers for extra capacity, ARA enables you to retain all your config on a single (pair of) machine(s). It also means that, if you have the framework to allow it, your customers can make changes to their own account themselves. -- Ishfaq Malik <ish at pack-net.co.uk> Department: VOIP Support Company: Packnet Limited t: +44 (0)845 004 4994 f: +44 (0)161 660 9825 e: ish at pack-net.co.uk w: http://www.pack-net.co.uk Registered Address: PACKNET LIMITED, 2A ENTERPRISE HOUSE, LLOYD STREET NORTH, MANCHESTER SCIENCE PARK, MANCHESTER, M156SE COMPANY REG NO. 04920552
Kannan
I have to disagree with Leanrod. We are a hosted (cloud) PBX company we
successfully run our Multi-tenant systems in Virtual machines and have no
issues with them. It comes down to designing your virtual environment for
your target loads and then not exceeding them. This allows for fail over of
hardware and scalability. We have moved our virtual phone switches live
with full call loads and have no call drops. We do not usually dedicate a
single Virtual Machine to each customer either. We have built our own
Multi-tenant PBX on top of asterisk. We achieve many of the features
available in freepbx/trixbox (not all). This method allows us to cost
effectively service our customers with a presence of scale in mind. It is
not uncommon to have 5000 + extensions per virtual switch. This method does
require highly skilled engineering to achieve stability.
Bryant
----------------------------------------
From: "Kannan" <vasdeveloper at gmail.com>
Sent: Tuesday, July 31, 2012 12:37 AM
To: "Asterisk Users Mailing List - Non-Commercial Discussion"
<asterisk-users at lists.digium.com>
Subject: Re: [asterisk-users] Multi-Tenant PBX with Asterisk
Thanks Leandro for your comments.
On Mon, Jul 30, 2012 at 6:35 PM, Leandro Dardini <ldardini at gmail.com>
wrote:
2012/7/30 Kannan <vasdeveloper at gmail.com>
Hi
I came across couple of pointers on the Internet regarding solutions
available for providing hosted PBX service.
1. Multiple PBXs: Using separate hardware to host each PBX. Pretty
straightforward, but no hosting company wants to use it. 2. Multi-tenant
PBX: Configuring multiple PBXs within the same instance of Asterisk. I.e.
partitioning a single instance of Asterisk into multiple PBXs by way of
configurations, using unique landing context for each tenant. 3. Virtual
PBX: Multiple virtual machines within the same hardware, each host an
instance of Asterisk.
Which one of the method above is generally used by hosted PBX service
providers?
Isn't the second option with ARA a good choice for dynamic creation of
multiple "small" PBX tenants?
Is the last option alone or combination of options 2 and 3 good for cloud
based hosted PBX service offering?
Thanks, Kannan.
Working in the voip field from a lots of years, I have found all three
type of business.
The first is maybe the easier and most common. Hardware is cheap and it is
easier to "sell" a service like the PBX if it is sold together with a
piece
of iron. Usually the hardware is placed on client's network, using the
bandwidth of the client. Usually together with the PBX is sold also a
router/firewall/traffic shaper/vpn endpoint to try to optimize the traffic
on the client's DSL.
The major pros about this solution is you can use a normal PBX like
freepbx/trixbox, the client can mess the config how he likes, without
disrupting other services, you can install VoIP card to connect landlines,.
The major cons is the cost of the hardware, the cost of the g.729 licenses
(if any) and the maintenance cost of replacing hardware failures and the
need to be physically near each client.
The second is the holy grail of the VoIP providers.
The major pros is the cost. Having a single hardware is cheap and it is
still cheap also if you decide to get two to be ready in case of an
hardware failure.
The major cons is the software. You cannot use the award winning
freepbx/trixbox family and you need to deal with sometime limited or
incomplete developed interfaces. The client always asks for the missing
feature. One other major cons is the "reload". If the PBX software is
not
made using ARA, then every time you add a new peer or a new DID, you need
to reload the entire PBX and that is a resource killer. Again, if the pbx
interface is not made using ARA, then you cannot let your clients to change
the configuration or they will trigger continuous reload (and delaying
reload for example every 10 minutes is not a solution)
The last one is sometime the chosen compromise, but from my point of view,
pbxes are not good software to virtualize. They are too sensible to delays
and your voice quality can go down if the real server is overloaded.
The same for the cloud based solutions (I have yet to found). I suspect
the "cloud" is good for services like http, not for real time
applications.
Leandro
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20120731/2c75e6d9/attachment.htm>