[asterisk-users] Multi-Tenant PBX with Asterisk
Leandro Dardini
ldardini at gmail.com
Tue Jul 31 10:19:45 CDT 2012
Hello Bryant,
it is nice to hear someone with different experience, so I am happy to know
the "cloud" is indeed a feasible environment even for VoIP.
Can you share with us some of your configuration magic? Like the cloud
service you are using, the power of each node and the load you are
experiencing on them in regards to the number of channels active and phone
registered?
Leandro
2012/7/31 Bryant Zimmerman <BryantZ at zktech.com>
> 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
>>
>
>
>
> --
> _____________________________________________________________________
> -- 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/88170142/attachment.htm>
More information about the asterisk-users
mailing list