In my previous blog posting, I introduced the concept of virtualization and why you can now consider virtualizing your voice/UC infrastructure, along with some of the basic benefits associated with virtualization. In this next segment, we'll discuss some of the key factors that should be considered to ensure that superior voice quality is maintained.
Of course, in most situations, voice communications is point-to-point, and in a VOIP system those calls are streamed point-to-point directly between endpoints. For these calls, the virtualized voice server acts as the call control, and processes the signaling needed to set up the call, tear it down, and invoke any mid-call feature such as putting the call on hold, call forwarding, etc. The voice server is not processing any of the media, or voice. The actual processing load on the server is relatively light and, although important, not to the same level of criticality as maintaining a voice path. However, in many situations, the voice server may also be acting as the media server and directly processing the media--such as when calls are bridged together with three or more parties--three-way calling, multi-party conferences, music-on-hold, and voice mail interaction come to mind. In some cases, these may be integrated as a single application, while in other cases, these functions may be carved off as separate dedicated applications--audio conferencing and collaboration servers, voice mail and unified messaging servers--all of which can be virtualized. It is in these situations--where the virtualized voice app is directly processing media--that it's critically important to ensure that the right voice/UC applications, the right virtual infrastructure and the right underlying hardware are in place. 
Voice Processing Application (Virtual Voice App)
In the graphic above, at the top of the stack is the voice processing application itself--this could be the voice server with embedded media processing, a dedicated media processing function, an audio conferencing server, or a voice messaging/unified messaging server. These functions, given the media processing task they undertake, tend to place a heavy load on the underlying hardware--be that physical or virtual CPU, memory, network I/O, or storage I/O. These resources can be even further taxed if sophisticated, resource-hungry compression techniques are used to optimize network bandwidth utilization.
In a virtual infrastructure environment, these physical resources are abstracted away and are used by many other applications running on the same physical server. The voice processing application must be able to provide some level of compensation for any delays that may be encountered in either accessing the underlying physical resources or reacting to delays encountered in incoming media packets. Of course, when processing voice, the two critical quality-affecting attributes are latency and jitter--both of which can potentially get hammered if underlying physical resources are heavily shared. One compensating factor for this can be found through the use of, and fine tuning of, advanced media buffering algorithms--usually referred to as jitter buffers.
Virtualization Hypervisor Technology
The hypervisor provides the abstraction layer between the hardware and the many applications running on a given server, enabling each application to run as if it believed it had its own dedicated server. The hypervisor performs critical scheduling tasks to ensure each application gets a slice of physical resource computing. For general-purpose business applications, the algorithms to manage the resource scheduling are not as critical. However, in the case of real time voice, where delays in packet transmission and processing can make the difference between toll quality voice and garbled voice, how the hypervisor manages the prioritization is extremely critical. Sophisticated hypervisors have been tuned to handle real time I/O and processing, and provide not only the right level of prioritization but also an additional level of fine tuning that an administrator can perform to ensure physical resources get allocated first to the voice application.
Server Hardware Technology
At the bottom of the stack is the actual physical server. Nearly all servers shipping today--except for perhaps the most basic entry level servers--come with sophisticated embedded hardware that optimizes for hypervisor environments. This was not the case only a few short years ago. However, with technologies such as Extended Page Tables and Rapid Virtualization Indexing, and a plethora of additional trademarked virtualization optimizations, modern-day servers are well equipped to handle a hypervisor abstraction layer with multiple virtualized applications. For this reason though, it is important to ensure that virtual voice applications are deployed in your data center on current server technology--typically of a vintage not more than two years old, such as Intel Nehalem or AMD Gen 3 servers.
Resource Reservation
In addition to ensuring that the selected voice application comes equipped to handle the task of running in a hypervisor environment--with the right algorithms in place to compensate for unexpected processing delays, the right hypervisor deployed in the data center that can prioritize real-time voice processing applications, and a data center equipped with current server technology--there is one more aspect that a properly configured voice application should undertake: Ensuring a minimum quantity of server physical resources are allocated to it. This is key when deploying voice applications in a mixed data center alongside other business applications.
Leading hypervisor technologies offer the ability to specifically reserve, or allocate, physical resources to a named application--resources such as the number of CPUs, GHz of CPU, GB of memory, and even Network I/O bandwidth and Storage I/O bandwidth. Doing so guarantees that a voice application has access to the resources it will require to maintain expected voice quality. However, such reservation should be applied carefully, as the whole purpose of virtualizing your voice application is to take advantage of consolidating it with other business applications on a reduced overall server footprint, in addition to the advanced management functions and availability capabilities offered by hypervisors and their higher-order management tools. Too much reservation will constrain your ability to take advantage of those management tools.
In our next posting, we'll talk about what it means for the Telecom group to "let go" of that dedicated telecom server and let it run in your virtual data center. In the end, who's actually managing it??
