Adopting an Open Source VoIP phone system

by John Yardley PhD, BSc, CEng, MIET (MIEE)

Managing Director, JPY plc

Revision 4: 15th November 2010

AbstractThis paper describes JPY's experience in deploying an Open Source VoIP phone system to replace a legacy analogue phone system. It gives a (not too technical) background to telephony and summarises the steps involved in migrating from one system to another. Although the document contains names of components which JPY used to implement its in-house VoIP phone system, JPY does not represent any of the manufacturers of these components and is not recommending any of them. If you have any comments or (constructive) criticism, please email them to This e-mail address is being protected from spambots. You need JavaScript enabled to view it .

Note: Where available, the first occurrence of each technical term is linked to a web resource with fuller discussion. If you are diving into the text midway, bear in mind that subsequent references to the same term are not necessarily linked.

opensource 1. Introduction

JPY recently decided to replace its existing (analogue) telephone system with a new (digital) telephone system. Our choice was between purchasing a packaged solution or building our own solution using off-the-shelf hardware, freely available Open Source software, and our existing Local Area Network (LAN) .

A packaged solution generally involves a single vendor who installs proprietary hardware (eg from a manufacturer such as Cisco, Avaya, etc.) and takes overall responsibility for a smooth transition between the old and new systems. The vendor also usually provides on-going maintenance and upgrades. Ideally, the vendor should provide a single point of responsibility.

The choice we made was to build our own Open Source solution. Even though the software was free and the hardware was relatively cheap, it did involve more of our time than a packaged solution would have. If saving money had been our prime objective (which it wasn't), it is unlikely we would have chosen an Open Source solution.

However, a large part of our time was spent in understanding issues that packaged systems often hide from customers (by the use of proprietary hardware). With hindsight, we would not have been in the position to make a rational choice between Open Source and packaged systems without this knowledge. Unless you have total trust in all sales people, there is no short cut to understanding your own requirements and what you are buying.

Furthermore, although it may not always be possible to cost-justify an Open Source solution against a proprietary solution, the major benefits come when the solution needs to be extended or modified - e.g. more handsets, home users, more lines, etc. We talked to several companies that were dependent on expensive outside consultants to administer their systems, and to some who were forced to pay large incremental costs for adding or moving lines or extensions. Even if you have no one technical in-house, the cost of training someone is generally less than paying a consultant on an ad-hoc basis.

no_support The downside of an Open Source solution is that there is no single contractor to hold responsible if the system doesn't work as intended. Indeed, if the Open Source software is not fit for purpose, then there is nobody at all to blame. Ultimately, you must just take a view on this.

The key to successfully implementing any new system is to do it a small step at a time, always with a fallback position. Even with a proprietary solution, if a wholescale replacement results in loss of service for some time, it is very little consolation that you can sue the supplier.

This document describes some of the technical and business decisions we made in taking the approach we did. It also concludes by providing a shopping list of the components we used.

Next section: JPY VoIP requirements...