Virtualising VoIP

As IP PBX vendors embrace non-proprietary platforms, the time is right for virtualising call managers. Maximising under-utilised VoIP/IPT servers are just one way to virtualise communications, as expert Gary Audin explains.

As the enterprise moves towards server virtualisation, does the VoIP/IPT server fit into the server consolidation scheme? The answer is a qualified yes.

The PBX was once a stand-alone proprietary system. With the advent of Voice-over-Internet Protocol (VoIP) and IP telephony (IPT), the PBX has become a server based system. In this tip, I offer arguments for why an organisation should and could virtualise VoIP and other communications services.

Why virtualise VoIP?
Whether or not you can virtualise your VoIP system depends on which vendor's VoIP/IPT server software you use. Some VoIP software only runs on proprietary servers and is not a candidate for virtualisation. Other vendors can run their software on standard Linux or Windows systems, making virtualisation a possibility.

The good news is that IP PBX vendors are moving away from offering proprietary products, producing software that can run on multiple vendors' server platforms. The proprietary server is loosing ground to the generic server, making it easier for the enterprise to consider VoIP virtualisation.

VoIP/IPT server, or the call manager
To understand when VoIP would make a good virtualisation candidate, let's first look at the functions of a call manager, or VoIP/IPT server.

A data center could benefit from virtualising call management servers because their resources are underutilised. The VoIP/IPT server is essentially idle for the majority of a VoIP call since the talk/speech path does not use the server at all. It's only busy for the first few seconds of the call setup and at the end of the call.

Let me explain. The VoIP/IPT server is not a telephone switch like the old PBX. This server is only a controller of calls. The server communicates with the endpoints, IP phones, softphones and gateways to establish the phone call. The endpoint communicates with the server requesting a phone call connection using a signaling protocol such as the H.323 and SIP standards or a proprietary protocol such as Cisco's SCCP (Skinny). The endpoint sends a call request packet to the server. The server then contacts the other endpoint to establish a call. The server contacting an endpoint is unusual for most IT applications. Once the server has been able to get both endpoints to accept the call, the server steps aside and the phone is established as a peer-to-peer connection that does not pass through the server.

Even during peak call hours, call manager resources are not fully utilised. Depending on the vendor, a server can establish 25,000 to 300,000 calls per hour called Busy Hour Call Completions (BHCC). The server handles about 6-10 short packets for a call attempt, which is not much traffic. Assuming that the server will setup 1000 calls in one hour, this is about an average of 2-4 packets per second. The server also receives 2-4 packets when the endpoints hang up. Therefore, one call completion is 8-14 short packets processed per call; again, this not much of a load.

Now, if you are operating a big call center, you might think that your server utilisation would be much higher. Yes, the BHCC would be much higher, roughly 5-20 times higher, in a call center as compared to normal telephone use in an enterprise. But, even in a call center, this is not s significant load. Why? The BHCC will decrease for longer phone calls. This is less call completion operation that the server has to support.

Unified messaging, communications virtualisation
Unified messaging (UM), which combines e-mail, voice mail and fax into one mailbox, and unified communications (UC), which combines UM with conferencing, collaboration and presence management, present more possibilities for virtualisation. UM and UC features are similar in operation to IP Telephony. The UM and UC servers will not be constantly busy and therefore will have underutilised operational periods. Virtualisation can be applied to UM and UC support.

VoIP virtualisation platforms
As I said before, the fact that VoIP servers are becoming more and more non-proprietary is a second reason why virtualisation is a good option.

Linux is one of the more popular VoIP/IPT operating systems. IP PBX vendors like 3Com, Intecom, Siemens and Broadsoft all operate on IBM servers running Linux. 3Com and Siemens can also run on the IBM System i computers. Other vendors can also run their software on Linux, but you need to check with them to insure their software can operate on the Linux you have in house. One smaller IP PBX vendor uses their own version of Linux that you must download with the IP PBX software. In this case, the IP PBX software may not operate in a virtualised environment.

VoIP virtualisation is not limited to open source platforms, of course. The Cisco version 4.X software runs on Windows. The Avaya IP Office and most of the smaller IP PBXs, serving several hundred stations also run on Windows. So, if you have a virtualised Windows environment, VoIP virtualisation is possible.

In summary, virtualisation can be an attractive option for an underutilised VoIP/IPT server and new software from an IP PBX vendor that runs on third-party platforms, such as IBM servers running Linux operating systems. Virtualisation can also reduce the number of VoIP servers you're using, thus reducing power and cooling requirements. As VoIP/IPT software vendors move from a hardware model to a software model that encourages virtualisation, expect to see this shift in the data center. About the author: Gary Audin has more than 40 years of computer, communications and security experience. He has planned, designed, specified, implemented and operated data, LAN and telephone networks for local area, national and international networks as well as VoIP and IP convergent networks in the U.S., Canada, Europe, Australia and Asia.

Read more on Collaboration software and productivity software