Virtualizing VoIP

As IP PBX vendors embrace nonproprietary platforms, the time is right for virtualizing call managers. And maximizing underutilized VoIP/IPT servers is just one way to virtualize communications, an expert explains.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

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 organization should and could virtualize VoIP and other communications services.

Why virtualize VoIP?Whether or not you can virtualize 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 virtualization. Other vendors can run their software on standard Linux or Windows systems, making virtualization 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 virtualization.

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

A data center could benefit from virtualizing call management servers because their resources are underutilized. 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 utilized. 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 utilization 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 virtualization 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 virtualization. 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 underutilized operational periods. Virtualization can be applied to UM and UC support.

VoIP virtualization platforms As I said before, the fact that VoIP servers are becoming more and more non-proprietary is a second reason why virtualization 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 virtualized environment.

VoIP virtualization 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 virtualized Windows environment, VoIP virtualization is possible.

In summary, virtualization can be an attractive option for an underutilized 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. Virtualization 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 virtualization, 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.

E-Chapter

0 comments

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy