Is it possible or advisable to virtualize a PBX system? How would one go about this?

I'm totally new to the world of VoIP and we are looking to move from our current provider to a solution we host ourselves, mainly because the current service is so unreliable. Unfortunately I know basically nothing about VoIP and what is necessary to get going. From what I understand, you need a minimum of SIP service, a PBX system, and hardware or software phones. I feel that this is an over simplification of what is necessary so more input on that would be appreciated.

Additionally, since all of our systems exist in VMWare ESXi it seems like it would be nice to virtualize PBX (like PBXInAFlash or OpenPBX, etc) in VMWare; however, I do not know if this is even possible or advisable to do. We have about 25 users and around 100 "Workgroups" in a call center style functionality.

So, I guess my questions are:

1. What is the minimum hardware and software and service(s) necessary to manage a VoIP system?
2. Is it possible to virtualize the PBX system?
3. If (2), is it advisable to virtualize the PBX system for an environment of about 25 users and 100 workgroups?

Solution 1:

All the answers to your questions are "it depends". If you use a PBX system like Asterisk where the audio data is actually handled by the server computers you'll have much steeper CPU and I/O demands on the server computer (along with finicky reliance on timing-- something that virtual machines don't necessarily do a great job with). If you a PBX system like sipXecs, which acts more as a "switch" with audio data mostly flowing between the endpoints (phones and gateway) you'll have much lower server resource demands but, obviously, a different feature set.

I think you're approaching this in the wrong direction. I'd start with identifying the telephony-related features you want in a PBX and then identifying products, platforms, and resellers who can provide what you're looking for. You can consider virtualization as a technical "want list" item the way toward developing a specification, but I'd argue that the telephony-related features should take precedence. Once you know what you're looking for, from a feature-set standpoint, you can begin to work out your hardware requirements.

Solution 2:

Virtualizing a PBX is a challenge, due to one main aspect: There is no guaranteed scheduling of your PBX VM and the general scheduling behavior could introduce jitter. That being said you also have to think about how your line-cards (if you need S0 to some other PBX etc.) need to be presented to the VM and if things like vMotion and HA make sense.

There are people at vmware that have done that and have been thinking how to run real-time like applications and have experience at doing that, but you have to speak to vmware directly to see what the current set of "working" products are.

Solution 3:

I've seriously considered this in the past and come up with one very good reason not to virtualize.

What happens if you want to connect your PBX to the standard PSTN network? Since doing so requires custom hardware it makes sense to avoid going virtual. This has the added benefit of if your SIP provider craps out you still aren't totally out of business.

Solution 4:

I wouldn't virtualise a pbx myself - the sipxecs developers themselves warn not to - they say not to consider virtualising anything except a test system.

I virtualised one myself with only 1 extension (host was a xeon e5450/12Gb with one core and 4gb dedicated to the vm) and found that voicemails were choppy.

If you really wish to do so anyway, I've read someone saying he dedicated 400MHz of cpu time to it which helped although I'm guessing this would vary dependent on your actual cpu.

Also from other experiments I've found the clock of a vm can bound around all over the show which doesn't help with stuff that is very time dependant such as an ippbx.

I'm not really a *nix guy but here's a discussion of some methods to try and stop the time jumping around http://communities.vmware.com/thread/108877

To be honest, I would never virtualise a pbx, or any router it is dependant on. Packets of data can normally wait split seconds without any issue but any delay whatsoever does not agree with voice.