This article originally appeared in the October 2010 issue of INTERNET TELEPHONY  

The implementation of open source voice over IP solutions has graduated from niche status to become a viable and increasingly popular approach for enterprise voice services. A 2009 research study by the Eastern Management (News - Alert) Group reported that open source PBXs captured 18 percent of the 2008 market – a 40 percent increase over the previous year, and more market share than any traditional PBX (News - Alert) manufacturer.

Platforms based on Asterisk and FreeSwitch offer IT managers comparable features to traditional telephony systems and prove more cost effective and easier to deploy and maintain. Despite the simpler and less costly approach, however, certain steps must be to taken to ensure maximum scalability and optimum voice quality in deployment of an open source VoIP system. Because VoIP runs on data networks, because open source telephony systems run on standard computing systems, and because these systems run on standard OSs, more careful attention must be paid to addressing capacity and quality issues that are either not as prevalent or not considerations at all in traditional TDM implementations.

Putting voice on a packet network and running telephony systems on standard computers change the rules of the game. As a result, there are several important hardware and software considerations to make to make sure all quality and capacity issues are addressed and the benefits of open source VoIP are fully realized.

Determining Optimal Payload Size

Voice traffic is placed into a packet network using the real-time transport protocol, or RTP. The nature of packet networks is such that a certain length of speech must be accumulated before sending out the packet, which consumes the processing power of the CPU. This means that determining optimal payload size can be a tricky task. If payload size is too large, the quality of the conversation can be adversely impacted because of the introduction of too much delay –which can result in awkward conversations with people talking over one another.

Typically, a range of between 25 and 150 milliseconds end-to-end delay is acceptable. To account for other delays such as jitter and voice compression/decompression, 30 milliseconds tends to be the upper limit. That means that the computing platform will create RTP packets for every single conversation at 30-millisecond intervals, ensuring a smooth conversation.

The Importance of Echo Cancellation

Echo is prevalent in any telephone network. In traditional telephony networks, echo was typically an issue only for overseas calls, or calls with roundtrip delays of more than 30 milliseconds. But in the case of VoIP, delays for calls are typically longer, which makes echo more perceptible to the human ear – so good echo cancellation is required on all calls, even if the call is between colleagues who are in cubicles next to one another.

Echo cancellation algorithms are very complex and processing intensive. While they can be implemented in software, this task is more appropriately addressed by utilizing specialized DSPs on telephony boards that can handle the load, which frees up the computing platform to process other important tasks. The VoIP phones selected for an open source implementation should be equipped to address echo cancellation as well, including the reduction of acoustic echo.

Selecting the Right Hardware

To prepare for an open source VoIP deployment, the configuration of the servers used to run the system must first be addressed. To ensure a scalable, reliable deployment, CPU occupancy and memory should be run in steady mode under 60 percent load to allow for peaks in traffic. RAID storage solutions should be utilized to maintain continuity and ensure adequate capacity to allow for functions like call data records and voicemail recordings.

Most standard computing systems do not come equipped with telephony interfaces, so accommodating an open source VoIP deployment means purchasing and installing PCI (News - Alert) or PCIe boards. These boards are not created equal, so careful consideration should be given to ensure an optimal deployment with the right features and functionality.

Telephony boards must continuously transfer voice buffers to the host CPU, so having the ability to configure the frequency at which this is done will help optimize the performance of the CPU. Some boards are hardwired to interrupt the CPU at every millisecond for every call to perform this task, while others are configurable for longer periods so that the CPU can be relieved to address other tasks. As with RTP packet sizes, there is a fine balance to keep between CPU occupancy and delays introduced.

On-board echo cancellation and on-board tone detection are other functions that take processing power away from the CPU and must be configured correctly. In addition, on-board HDLC framing, which is required to pass call control protocol data such as ISDN D-channels from the network to the host, consumes CPU cycles.

There are many other considerations, such as network design, on which we have not touched. But clearly, deploying an open source VoIP systems introduces a lot of changes and requires careful consideration of many network settings and functions, as well as the right selection of hardware and computing platforms. When deployed correctly following these guidelines, VoIP systems based on open source can provide high-quality and efficient voice communication for enterprises.