Adopting an Open Source VoIP phone system

This 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.

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.

by John Yardley PhD BSc CEng MIET (MIEE) 
Managing Director, JPY Ltd
Copyright © 2010 JPY Ltd
Revision 4: 15th November 2010

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.

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 wholesale 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.

2. JPY VoIP requirements

JPY is a software company that has been trading since 1982. We provide server software products to clients who need to publish or share documents. We have a lot of customers in the publishing industry - who use Macintosh and Unix - but we also have many clients from other business sectors where PCs are prevalent.

Because we buy and sell products and services, we use our telephone system like any other business. We run a dedicated office which has 8 telephone lines, of which 4 are routed to 20 desktop extensions. Our business relies on good Internet access and so we do not share our Internet service with anyone else - as happens with ADSL. Some of our employees work from home or while travelling and, for those staff, we prefer to put incoming callers directly through rather than tell the caller to dial a different number - in short, to appear as though they were in the office.

Most JPY staff have Macintosh workstations on their desktop and use the iPhone for mobile telephony. 

One of our less conventional business practices is that we share messages among staff. Messages are primarily email, but also include text messages, instant messages (Skype) and, importantly in this context, telephone calls stored as digital files.

Of course, we have confidentiality policies, so personal and confidential messages remain private, but by and large, any member of staff can instantly see any messages in or out of the company. This may seem a recipe for information overload, but in reality is very successful (for us) because shared messages are only ever looked at as coherent "threads".

For example, when dealing with a particular customer support problem or sales enquiry, - which we call an incident - there may be several JPY staff and several customer staff involved. Simply looking at one staff member's mailbox may say very little about the incident. However, when all the mail relevant to a single incident is threaded together, it paints a remarkably different picture of what is going on. Furthermore, in some cases, we give our customers access to threads that relate to them. They are often amazed at how many of their staff and our staff are involved - sometimes quite oblivious of one another.

We don't share message threads for fun or to create any sort of "big brother" environment. We do it because it greatly improves our business efficiency and saves us money. Staff can share tasks without having to poke around in colleagues' mail accounts, and in general, they work much better when they can see the whole trail of events.

This works very well for JPY because messages (mainly email and their attachments) are the "currency" of our business. Nearly all incidents and transactions result in an email. Simply by searching the shared message database, staff can provide instant answers to customers that would ordinarily have taken hours to elicit. We understand that this may not work for all companies.

A natural extension (no pun intended) for this system was to include voice messages in the threads, and this was part of the requirements we had in choosing a telephone system. (VoIP has since become an integral part of our Threads project.)

In summary,

  • JPY is a software company with in-house expertise on networking
  • JPY uses 8 land lines and 20 telephone extensions
  • JPY uses Macintosh, PC and Unix computers, primarily (but not exclusively) Macintosh as the workstation of choice
  • JPY maintains an Internet service not shared with other subscribers
  • JPY has the need to allow home and remote employees to communicate as though they were in the office
  • JPY has the need to be able to selectively access and store telephone conversations

3. Tutorial/Primer

Most businesses will have one or more lines from the telephone exchange entering their premises. These are often called landlines. The number of landlines determines the number of calls that can be "on the go" at the same time. If a business has more employees than landlines, or their premises are geographically spread out, they may want to have several telephones - often more telephones than they have landlines. This is OK because not all the telephones will be in use simultaneously, and some may be in use only for internal conversations.

The device that connects the telephones together and routes calls to the landlines is called a Private Branch Exchange or PBX. It is sometimes called a Private Automatic Branch eXchange - automatic because it doesn't require a human operator to route the calls.

There are many types of PBX but the BT (formerly British Telecom) Meridian (manufactured by Northern Telecom) was a very common one in the UK. The wiring that connects the phones and the PBX together is called a private network. The wiring that connects the PBXs of different companies together through the telephone exchanges is called the Public Switched Telephone Network (PSTN).

If the PBX was purchased before about 2005, then it was probably an analogue system. In an analogue system, the speaker's voice sound is converted directly into electricity by the handset microphone. It is then sent to the listener's handset where it is converted back into sound in the handset earpiece. This electrical signal is a replica of the sound wave coming into the microphone. The louder you speak, the larger the electrical signal you generate. In an analogue system, the PBX interface to the landline is often called a Foreign eXchange Office (FXO) and the handset a Plain Old Telephone Service (POTS).

More recently, analogue systems have been superseded by digital systems. In digital systems, the speech is converted into a series of data pulses which are converted back into sound at the other (listener's) end. With digital systems, the loudness of your voice makes no difference to the amount of data sent. However, if you are silent - e.g. when pausing or listening, then no data is sent at all. A similar change from analogue to digital technology has happened in audio recording and broadcasting. For example, analogue vinyl records have been replaced by digital CDs; analogue FM radio has been replaced by digital DAB radio; analogue VHS video tapes have been replaced by digital DVD disks.

The main reason for replacing analogue systems with digital systems is that they are less prone to interference and that they use the wires more efficiently and hence cost less. And we mean here much less. A wire carrying one analogue conversation could be carrying 10 or more digital conversations. This is generally called multiplexing.

Replacing an analogue phone system with a digital phone system gives all these advantages. However, since many companies already have digital computer networks, these networks (i.e. the wires) can often be utilised to run their digital phone systems. This gives major benefits because it is unnecessary to have two separate lots of wiring - voice and data. Provided the digital phone system obeys certain rules (rules are called Protocols), then it can share data over the computer network. These rules fall into a general group called Voice over Internet Protocols. A bit of a mouthful, so often abbreviated to VoIP.

3.1 VoIP Systems

So, in a VoIP system, the wiring used is standard computer network wiring (Ethernet). The telephone (extensions) behave in much the same way as those on an analogue system, but their connection to the PBX is via a standard computer network connection, Ethernet. Phones are connected to the network just like PCs.

While it may not always look like it, the PBX is a general-purpose computer running an operating system such as Windows or Unix. It is connected to the landlines by means of a special interface card.

The simplified diagram above shows the Internet connection directly to the PBX. In reality, the Internet connection would come via the general office network, which is connected to the Internet via a device called a router.

VoIP is just a general term and there are various different VoIPs. The prevalent protocol for use within an office or local network is called the Session Initiation Protocol or SIP.

Programmers who write software that communicates with the PBX, will not want to do so by assembling low-level packets of information which must obey all the communication protocols. To make life easier for programmers that wish to write programs to interact with a network service, the service provider often makes an Application Programming Interface (API) available. Many manufacturers of commercial PBX systems adopt the Messaging Application Programming Interface (MAPI),  a proprietary API developed by Microsoft. Anything proprietary is not generally good news for Open Source systems, and indeed, MAPI is not easily supported under Mac OS or Unix (at the time of writing). 

3.2 Landlines

The landlines which come in to a building carry electrical signals with both the speech information in the call itself and extra information to route calls. For example, the number of the caller and the called person's extension.

In the simplest scenario, that is without a PBX, you could connect each of your landlines to a single telephone. Telephone companies provide the facility for telephone lines to be grouped together using a single telephone number such that if a call is made to a number that is engaged, the call is automatically routed to a non-busy landline. This is called line hunting.

Needless to say, it would be inconvenient if you had to run to a different office to answer the next available phone, so the main job of the PBX is to let any phone connect to any line.

Landlines are sometimes analogue; sometimes they are digital right up to the subscriber's premises and converted to analogue so as to be compatible with existing analogue phones; sometimes they are a combination of both, where digital data is superimposed on analogue signals. This is called modulation. It often depends on the type of wiring used to deliver the service.

An important factor with analogue landlines is echo cancellation. The theory is quite complex, but stated simply, if any transmission line is not correctly terminated, then signals can echo back down the line. Sometimes it may be beyond the subscriber's control to affect the termination, and to overcome this some PBX interface cards provide special electronics to cancel out echo signals. These are generally more expensive than cards without hardware echo cancellation, but the extra cost is generally worth it as echoing can be difficult to eliminate and is very off-putting for callers.

3.3 Holding on to your phone numbers

If you are replacing your telephone system, you probably want to continue to accept calls to your existing telephone numbers - otherwise you will have to set up a "redirection" service or inform everyone that is likely to phone you that your number has changed. Since changing phone numbers often goes hand in hand with changing your phone service provider, there is not a great deal of incentive for your old service provider to make sure the redirection happens smoothly. Furthermore, if you change your phone numbers, your phone service provider and phone system all at the same time, if something doesn't work, it will be a nightmare to find out which is the culprit.

It is therefore recommended that you stick with your existing service provider and telephone numbers until such time as the new PBX is thoroughly proven. This may involve a little extra expense, but this is more than worth the saving in disruption if things go wrong.

Once you are satisfied that your PBX is operating as you want, you may want to change your phone supplier. You may even be able to do without a phone supplier altogether by making and receiving calls via the Internet.

3.4 Internet Gateways to the public switched telephone network (PSTN)

Once you have a successful VoIP system that can allow users to make internal and external calls via existing telephone lines, you may be wondering if you can do away with your telephone lines and connect to the public telephone network via the Internet.

This is certainly possible but it depends on a number of factors.

First of all, although many companies now have VoIP systems, telephone contact is made using the telephone network. In order for a company to avoid having landlines, it must find a way for incoming and outgoing VoIP calls to get off and onto the public phone network. The is called the gateway and usually, the gateway is at the VoIP system users premises.

However, many service providers have set up dedicated gateway services so that subscribers with acceptable Internet connections can do away with their telephone lines altogether. This may mean obtaining a new set of telephone numbers, but, depending on the original telephone company, it may be possible to assign existing numbers to the gateway provider with the obvious benefit that the telephone number is unchanged.

Using a gateway provider can offer economies of scale. The gateway provider will often be able to offer better call rates than a phone company. Additionally, the cost of an Internet connection is generally cheaper than that of analogue telephone lines (for the same amount of data). Last, but not least, if two companies have VoIP systems and use the same (or cooperating) Gateway providers, then their calls can be routed entirely through the Internet.

The downside of using a Gateway provider and doing away with landlines is that you become totally dependent on your Internet connection. If it fails, you may lose most of your main forms of communication.

Furthermore, once you have decided to assign your telephone numbers to the gateway provider, you remain in the twilight zone and can only hope for a smooth transition.

A good half-way house is to maintain telephone lines for incoming calls and use the Internet for outgoing calls. This removes the problem of lost communication during an abortive number change, but achieves the economies of scale only possible from a gateway provider.

In this scenario, an outgoing call may be routed via telephone lines or the Internet, as practical or economical. It reduces the dependence on the Internet.

Many PSTN subscribers now use a facility called Caller ID which provides the caller's number before the call is picked up. Bearing in mind that outgoing calls will make their way onto the public telephone network via the gateway provider's telephone lines, those receiving calls could be confused about the originator of the call. Clearly something not desirable.

To overcome this, most gateway providers allow subscribers to assign their landline number to any outgoing calls. Needless to say, the subscriber must satisfy the gateway provider that they are providing their legitimate landline number, but given this can be done, anyone receiving calls would be unaware the call had not come from the originator's landline.

Of course, commercial gateway providers are not charities, so must charge if they route calls onto the PSTN. In our experience though, the overall cost of calls is much lower than it would be if using dedicated landlines.

3.5 Changing your telephone wiring

Again, if your existing phone system is more than 5 years old, the chances are that it will have existing dedicated wiring to connect phones to the PBX. One of the benefits of a VoIP system is that you can use the standard (Ethernet) data network that connects your computers to connect your phones. Obviously, the major benefit of this is that you do not have to maintain two sets of wiring - one for computers and one for phones. Furthermore, you can also automatically benefit from wireless networks and place phones wherever you have wireless coverage.

It is important to realise that voice data is special in that it is crucial it is transmitted without interruption or delays - otherwise the parties will not have an easy conversation. Clearly if midway through a telephone discussion, a user downloads a large file from the Internet, it would be anarchy if the conversation broke up in some way.

For this reason, voice data has to be given a special high priority and certain devices on the data network need to understand this, so that it is delivered before any other service. How this is achieved we shall explain later, but the upshot is that it is not always possible to run a phone system on an existing network in a way guaranteed to give the best user experience.

Faced with this situation, many VoIP system manufacturers will not take the risk that a customer's network will provide a good enough basis for use with a phone network. Their alternative is to provide their own dedicated network which may, of course, nullify one of the major benefits of VoIP.

A network designed to carry voice data will usually be perfectly adequate for general data communication but not vice versa. Hence, manufacturers will often encourage customers to adopt their telephone network as the computer network. While this is fine, it tends to lock the user further into dependence on the manufacturer so that whenever a network change is required, the customer is forced to contract an approved third-party to do the change.

Furthermore, while certain components on a computer network may not be good for voice traffic, the basic wiring is likely to be suitable. But few phone system manufacturers would be prepared to condone the use of existing cabling as this would probably involve the reseller in as much work in testing as it would be to replace it wholesale. It is the cost of wiring installation that is often greatest because of the geographical issues involved.

So in summary, if you wish to use an existing network and need to be guaranteed that voice traffic will be handled as well as with a dedicated voice network, then you will need to make sure it is suitable. This is covered in the next section. Nevertheless, while it may be technically unsuitable, in practice, it may be adequate. It depends on the amount of voice and data traffic

3.6 Using your Ethernet LAN for VoIP

The network used for computer communication within an office is commonly known as a Local Area Network or LAN.

Relative to the capacity of a typical office network, speech does not generate a lot of data. However, it is essential that it is delivered quickly if conversations are not to stutter or break up.

One way to achieve this is create a separate LAN just for phone data. That is, two sets of wiring. This would be expensive and rather defeat the original objective of using a data network for speech. The alternative is to create what is known as a Virtual LAN or VLAN. In this scheme, only one set of cables is used but the devices (called switches) that connect the cables together can segregate the data according to the its type just as though each had its own cable. It is thus possible to separate general data (files, etc) from telephone (voice) data and give the voice data a guaranteed proportion of the cable capacity (also called bandwidth). This scheme is known as Quality of Service (QoS).

Although speech data may only be a small proportion of the data sent through the cables, without Quality of Service, during times of high network activity, it can be delayed enough to degrade a conversation.

QoS  and VLAN both require that switches deployed in an existing network can support these features, and that someone has the expertise to set them up.

For internal VoIP calls - i.e. extension to extension - it is quite possible that QoS and VLANs would not be necessary - or that occasional conversation degradation is tolerable. This is because most modern networks have a very high capacity and even at busy times, they are far from saturated.

But when using the Internet to connect to the PSTN - i.e. for making and receiving external calls - then the situation is quite different. While LAN network capacities of 1 Gigabit/sec (1 thousand million bits per second) are common, connections to the Internet are typically much slower. Indeed, the type of Internet connection you have will determine whether or not you can dispense with your landlines and use an Internet gateway.

A final consideration for the LAN whether it is possible to draw power from it. Most devices that connect to a LAN will have their own power supply. For telephone handsets, this might be less convenient because of the need to provide mains sockets as well as LAN (Ethernet) sockets. To allow devices to draw power from Ethernet instead of providing power locally, its necessary for the switches that connect the network together to support Power over Ethernet (PoE) .

3.7 Internet connections suitable for VoIP

A telephone conversation will normally be limited to 64 Kilobits/sec of data transfer. Therefore, if you have 6 existing landlines that you hope to replace with a Internet gateway, you will need to have 384 Kilobits/sec available at any time.

Most small to medium-sized companies will use ADSL lines to connect to the Internet. The important letter in the ADSL acronym is "A" for asymmetric - which means they can receive data much faster than they can send it. Mostly, this is fine because Internet users are generally downloading or receiving data. But a speech conversation usually involves each party speaking 50% of the time.

A 1 Megabits/sec ADSL line means it can download data at up to 1 million bits per sec, but it can typically only upload data at say 100 Kilobits/sec. In the above example, trying to use a typical ADSL connection to support 6 external telephone connections would not work.

A further complication is that ADSL lines are low cost because their capacity is shared amongst many subscribers - perhaps as many as 50 users to one channel. So, it may be that you are sharing the same line with lots of different businesses and private users. The number of subscribers sharing the line is called the contention ratio. The capacities quoted by the phone companies are only average values. If all 50 subscribers happen to be accessing the Internet simultaneously, then each will get very poor performance - perhaps disastrously poor for speech users.

There are several possible solutions to this...

Use an ADSL connection with a low contention ratio and sufficient upload capacity - these are often advertised a "Business" ADSL. Use a Symmetric DSL (SDSL) connection with a low contention ratio where the upload and download speeds are the same - these appear to be falling out of favour and are of limited availability in many exchanges. Some proprietary VoIP systems will include the provision of an SDSL line dedicated to voice. Use an uncontended (ie unshared) "managed service" with identical upload and download capacity - these services are significantly more expensive than ADSL.

In any of the above cases, the issue of Quality of Service for external calls is much more important than for internal calls. Clearly there is far less of a problem in handling 512 Kilobits/sec of speech data inside a 1 Gigabits/sec local network than there is on 1 Megabits/sec Internet connection. In short, the Internet connection can only be utilised reliably if sufficient bandwidth can be guaranteed for speech data.

3.8 Remote Connections

If you have staff that work from home that you want to "appear" in the office - by this I mean you can transfer incoming calls to them - you need to consider remote connections to your VoIP system.

Each home worker must have a network connected to the Internet. It may be a very small network with perhaps just one computer and a printer, but it will be a network nonetheless. You can add a VoIP phone to the home network but because it is regarded as a different network to the office network, it will not generally be possible to exchange calls between the office and home networks. This is largely a security issue.

The way around this is to join the home and office networks together so they appear to be one network, called a Virtual Private Network or VPN. Indeed, it is possible to join many networks together in this way so they appear as one network.

Setting up a VPN can be straightforward, but unless you have a good understanding of what is going on, it can be difficult to find out what is happening if it doesn't work. It's therefore a job best left to a specialist.

But there are some things that you need to consider when deciding on whether you wish to set up a VPN. First of all, as previously mentioned the device that connects your Internal network to the internet is called a router. Sometimes a secondary device called a firewall is placed between the router and the network. Sometimes the router and firewall are in the same box.

The firewall or router may be responsible for creating the VPN and it is only possible to create a VPN if this functionality is available at both ends of the network connection - e.g. the office and home. Sometimes, home routers are not sophisticated enough to support VPNs, so a compromise is to run VPN software in the home user's computer. While this is feasible, it relies on the computer being running all the time that remote phone calls can be made. This tends to be impractical, so generally, to operate a remote extension will require each home user to have a dedicated firewall that supports VPNs.

While this may all sound complicated, it is no different for packaged VoIP solutions and often remote extensions are very expensive to set up. But a home VPN confers many other benefits on home users, so is definitely worth considering.

4. Theory into Practice

So much for some of the theory. Given you have decided to go the Open Source route, what are the practicalities? Here we look at the JPY implementation of VoIP.

I have stressed the importance of always having a fall-back position. In going it alone, it could damage your business if lose your connection to the public network (PSTN) and cannot get it back without outside help. You could be well and truly up the creek (without a paddle). In the following text, I have tried to make fallback decisions clear.

I am assuming here that you have an existing internal phone system that you wish to replace. Clearly if you are starting a new business from scratch, there is no position you need to fall back to.

The first thing you must consider is how to connect your new system to the PSTN. Next, you need to decide whether your existing computer wiring (LAN/Ethernet) is good enough to run computer and voice data together. Third, you must decide on the the software you intend to use for your private branch exchange (PBX). And finally, what phones you wish to use. Of course, none of these decisions can be made independently, but it is helpful to tackle them in these chunks. In practice, you may need to look at them in a different order.

Although the system implemented at JPY was the end-result of much research, this document is not intended to be a product review. At each of the stages above, decisions must be made. What follows were the decisions we actually made that we felt were appropriate for JPY. They will not necessarily be appropriate for other businesses, hence the inclusion of section 2 describing the JPY profile.

4.1 Legacy system

Our legacy telephone system comprised a BT Meridian analogue PBX, 16 x BT Meridian desktop telephone extensions connecting 4 analogue land lines. In addition, we had 4 additional analogue land lines for devices such as fax, alarm system monitoring and dedicated lines.

Our initial Internet connection was a 2Mb/sec managed service. This provided 2Mb/sec upload and download speed and was not shared with any other subscribers (this is called un-contended). This was subsequently upgraded to 10Mb/sec.

4.2 PBX Software

The most fundamental decision to be made is the choice of PBX software. At JPY, we had some special requirements.

Although we run some Windows PC systems in-house, most user workstations run Mac OS X and our preferred server operating system is Linux. Even though we use dedicated telephone handsets, the user workstation often needs to interface to the PBX - either for setting up the PBX, for setting up the handset or for dialling numbers stored in a database.

Mac OS X is not well supported by manufacturers of proprietary PBX systems and the choice of an Open Source PBX was partly imposed upon us by the need to integrate our Customer Relationship Management (CRM) system and with employees' OS X workstations. In fact by choosing a PBX and handset that uses a Web interface, we were guaranteed future interoperability.

After much deliberation, we chose the Asterisk PBX software .

The main reasons we chose Asterisk were as follows:

  • It is Open Source
  • It runs under Linux
  • It has an Application Programming Interface (API) 
  • We had good reports from trusted users
  • There was a good range of supported interface cards for connecting UK telephone lines
  • It provided all the intrinsic PBX functions we needed

Asterisk is configured using its own scripting language. This provides great flexibility but is not user friendly. Asterisk does not provide web access, it does not have any database in which to store call or user statistics nor any way of managing user handsets. However, these features are available with another Open Source product called FreePBX. FreePBX, in turn, uses the functionality of other Open Source products, the Apache web server, and MySQL database server.

As you may imagine, all of these individual Open Source products have to be individually installed onto the server, which does require systems management expertise. To help overcome this there are some commercial solutions that combine Asterisk with other Open Source products to make the installation and management much easier. The solution JPY chose was called Trixbox. Trixbox provides a CD installation containing all the necessary components to run and configure Asterisk. The setup is achieved using a standard web browser from any workstation on the network. Although Trixbox is a commercial product, the Community Edition is available free of charge.

The Trixbox web front end allows the system manager to configure the whole system. It also allows individual users to maintain their own extensions and perform operations such as downloading recordings of telephone conversations.

4.3 PBX Hardware

Given the fact we needed only a generic Linux server that could support phone line interface cards, we had an enormous choice of hardware.

In the end we went for a DELL PowerEdgeR300 server with the following specification:

  • 1U rack mount
  • Quad-core Intel Xeon Processor
  • 2GB memory
  • 2TB SAS storage
  • Redundant power supply

The mains power to the server is fed via an Uninterruptible Power Supply (UPS). This device contains a bank of batteries and if the mains power fails, then the UPS maintains power for a short period of time - depending on the capacity of the batteries. While long term power failures in Surbiton are rare, those lasting a few minutes are more common. The UPS ensures that the telephone system is not disrupted for these short power losses.

Connections to the telephone network are made using a PCI card manufactured by a US company, Digium - the original developers of Asterisk who made the wise decision to publish Asterisk as an Open Source product to help sell their interface cards. Although cards from other manufacturers apparently will work with Asterisk, we took the view that choosing Digium cards was a safer bet.

There are many variants of these cards supporting 4 to 24 lines - both analogue and digital.

4.4 Telephone Handsets

Asterisk communicates with telephone handsets using a protocol called SIP. SIP-compatible handsets are manufactured by many companies, but our choice was the Snom 320 . This handset combines five things:

  • Good human factors
  • Ability to customise the display and key functions
  • An integral web server so the handset can be set up, monitored and controlled from a web browser
  • May be powered locally or from the network (PoE)
  • Well engineered, with good weight and high-quality materials

The web server feature of the Snom 320 was essential for us to be able to drive the handsets from Macintosh workstations. This allowed us to, for example, dial numbers from our internal CRM system without touching the handset.

4.5 Landlines

Connecting to the existing landlines consumed a large portion of all time spent on our VoIP transition.

Like many other established companies, JPY had been the target of many years engineering abuse from BT. Analogue lines entered the building in a single trunk of (50) twisted pairs terminated in a single junction box. From here, individual connections were made to sockets around the building, and a further trunk taken to the main Meridian PBX. The junction box wiring was an complete bird's nest, having reached the point where its cover would no longer fit due to the bulk of discarded wiring. BT appear to have the policy that, when any line is changed or disconnected, then the old cables should just be left in there. After 15 years, this made it virtually impossible to identify incoming lines without special test equipment. Equally confusing was BT's practice of using any convenient internal pair to route and re-route extensions. Several landlines (for fax, etc) were routed through the building using redundant pairs in unused wiring, some not of BT's original installation.

Our first requirement was to run the 4 main exchange lines into our computer room where they could be connected to our new VoIP PBX computer. However, we needed to maintain the BT connection to the Meridian system. Fortunately, analogue exchange lines have the property that you may connect several pieces of equipment to them in parallel.

Although we had the expertise to do this internally, we decided it would be prudent to contract BT to do the work since their wiring was so fragile, we did not want to risk losing connection to the Meridian. This is where things became difficult.

Gone are the days when you can dial "ENG" and get an engineer to call. Now, you have 6 levels of automated assistant, some ending in infinite loops. Eventually you discover, as if you should have known all along, that there are two companies, BT and OpenReach, and by definition you are speaking to the wrong one. Indeed, both are wrong because BT has franchised off all its small company work to third parties. When you finally make contact, you are given the third degree about why you are not getting a new BT VoIP system. Explaining that you have Macintoshes appears to satisfy that requirement, and then you are told you can place an order for an engineer to visit your premises - but it will take 3-4 weeks for an appointment. We were advised to make a "fault" call, then ask the engineer on arrival request for the line extensions to be connected on a time/materials basis. This did not work either, although the engineer that arrived was cooperative enough to hang around while we identified the fragilely connected lines. We had no choice but to make our own connections (seen in the pictures as the two purple cables, each carrying two twisted pairs to the computer room).

Our ultimate objective was to connect 4 exchange lines entering the building to a computer that would be used as our VoIP PBX. This involves a special interface card, which typically accepts 4 lines. Cards can be purchased that support ISDN lines, and since ISDN carries multiple calls on the same connector, it is generally more compact.

We decided that we would initially only connect a single exchange line to ensure we could make and accept calls to the PSTN without interfering with the Meridian system. We had a spare line that we could use without affecting the main office numbers. Once proved, we tested the same line on each socket on the interface card.

5. Summary and Conclusions

If you have come straight to the conclusion to see if it's worth reading the background, then hopefully this will provide a useful summary.

  • JPY's initial Open Source PBX configuration involved the following components...
  • 4 landline (FXO) interface card with hardware echo suppression (Digium)
  • PBX Server Hardware (Dell)
  • PBX Open Source Software (Linux, Asterisk and Trixbox)
  • 17 local handsets (Snom)
  • 3 remote handsets and firewalls (Snom + Sonicwall)
  • Network modifications for VLAN (VLAN) and QoS support (HP switches)

The total cost of these components was £5,010. This included the necessary upgrades to LAN switches which may not be necessary if you already have switches suited to running telephony over your LAN. It does not include the cost of the Mac Mini evaluation/test server which we had already, but if this was purchased, then it would have added another £550.

The internal time spent on evaluating and deploying the server was about 20 man/days spread over a period of about 2 months. Charging our internal time out at £300 per day, this would have added £6,000 to the hardware cost giving a total cost of the system of £11,000. In reality, this time was written-off within overheads, and had we had the benefit of reading this paper, would likely have involved half this time.

It is not easy to compare this directly with the cost of purchasing an off-the-shelf system because at the time we obtained quotations, we didn't really understand enough to accurately specify what we needed. We felt it would have been unreasonable to obtain quotations retrospectively just for the purposes of finding out how much we might have saved. However, those quotes that we did obtain at the outset were about £7,500 for a 10 phone system with no facility for remote handsets. Furthermore, of the 20 man/days spent on the project, a significant proportion of time was spent learning and this would have been equally necessary with total reliance on outside consultants.

Nevertheless, expertise is needed to set up an Open Source PBX system and it is not something someone without system management skills would find easy - particularly without Unix/Linux skills. 

5.1 Areas of Difficulty

The physical connection of analogue lines to the PBX server presented the greatest challenge. This was made difficult by the fact that the landline service  provider (BT) had over the period of many years since our building was constructed, left a complete and undocumented mess of wiring - rarely removing redundant cables and making use of any available pairs to reduce work. It took much time to sort this out and BT had no interest in assisting us connect a non-BT PBX.

Once the lines were connected, echo suppression posed quite a problem. There were issues in getting the gain (volume) correctly adjusted on the interface cards which came down once more to inconsistent line termination and incorrect polarity at the master BT junction box.

Setting up network switches and firewall to support VLANs was also not easy.

5.2 Benefits

Soon after deploying the new VoIP system, benefits were available. The Open Source architecture of the PBX meant nothing was hidden in terms of configuration and there was a vast resource of expertise available on the Web to help troubleshooting. The general PBX facilities provided were more modern and the call quality generally better and more predicable.

There are a few benefits worth singling out...

  1. CRM dialing: The openness of the web-based front-end to the telephone handsets meant that we were able to configure our Mac OS X based Customer Relationship Management (CRM) system to dial outside calls directly from the contact record.  Not only did this save time dialling numbers, it encouraged staff to add records to the CRM. This was particularly important as no proprietary system provider seemed to be able to demonstrate anything more than the most basic integration with Mac OS X.
  2. Web configuration: The ability to manage the telephone system and individual handsets from any web-enabled computer was a major advance on the previous system.
  3. Remote extensions: By use of a virtual private network (VPN) and appropriate firewalls, we were able to run identical handsets at employee homes. These appeared to the system as regular (local) extensions so that calls could be made and transferred just as though in the office. Staff could work from home exactly as they did in the office. However, there was no cost for calls (since they were routed via the Internet) and more importantly, no additional payments to the PBX supplier. This appeared to be one area where costs of off-the-shelf systems were disproportionate.
  4. Soft and SIP phones: The use of SIP in a VoIP system allows the use of desktop or laptop computers and smart phones (specifically the iPhone) to act as handsets. This means that, for example, a user can nominate his/her iPhone as a default extension. If the iPhone is located in a WiFi zone (anywhere in the world), then call charges are as per in the office.
  5. Call recording: One of the initial design aims was to be able to collect each completed call as a digitised audio file (MP3) and intelligently add it to a "thread" associated with a specific outside person - caller or called. Although it was thought there would be benefits of immediately (and at will) being able to replay a conversation, in practice this turned out to be an almost indispensable feature - simply because, on many occasions insufficient notes were taken, and it obviated the need for a further call. Other times, it was important for another staff member to hear the conversation.
  6. Expandability: The open nature of the whole system meant that additional extensions could be added at only the cost of the handset.

5.3 Conclusions

We believe the Open Source VoIP PBX solution we adopted has given JPY a lower cost, more flexible system than would have been possible using a proprietary off-the-shelf system.  However, while an Open Source PBX can provide a good solution for many companies,  the system management expertise required to set it up from scratch should not be underestimated.

There are many reports of corporate users adopting similar Open Source products, and we have no reason to believe it will not scale extremely well to companies many times the size of JPY. We believe there are many more benefits to come as the system becomes more integrated with our CRM system.

5.4 Acknowledgements

I'd like to thank Dave Fox, JPY's technical manager and Dave Cole, a JPY principal consultant for all their efforts in researching, testing and deploying the system. I'd also like to than John Sidney-Woollett without whose encouragement and previous experience, we may not have pursued the Open Source route. is a very useful resource for all things VoIP, but don't be put off by the home page which doesn't appear to lead you anywhere. Either search the site for items of particular interest or over over the "Quick Links" link to view and select an appropriate option.

John Yardley, JPY limited, Surbiton, Surrey, England KT6 4TW
Copyright © 2010 JPY plc