Why TiGra Networks Chose TrixBox For Our Telephony Offering
In November 2007 TiGra Networks embarked on a project to evaluate various digital telephony solutions, with a view to implementing our own infrastructure and, in the process, gain the necessary knowledge and experience to offer digital telephony solutions to other businesses. We are now ready. After months of trying various alternatives, we settled on TrixBox CE (Community Edition). Today we operate two linked digital exchanges across two sites in South Wales with multiple extensions in three locations spread around the UK. Our system provides least cost call routing, ‘Follow Me’ features enabling incoming calls to find us wherever we are, voicemail with email integration, integration with our Microsoft CRM system, click-to-dial from Microsoft Outlook and many other such features that you’d expect to find on enterprise PBX systems costing many thousands of pounds. We can now offer our solution to SMEs at a very reasonable price for an entry level system that will scale to hundreds of users.
This paper documents why we chose our final solution, TrixBox CE, and how we arrived at that decision.
Begin With the End in Mind
Our primary motivating factor was the provide the end user with the best possible experience and a rich set of features that you'd expect from a 21st century digital telephone system. We decided to focus on Cisco 7900 series IP Phones, a high quality industry-proven device, connected both directly and via the Internet for tele-workers. I worked as a firmware engineer in the telephony industry for around 20 years. Having worked for Nortel Networks on digital telephony products and then for Cisco Systems on their IOS operating system and worked on the firmware development of many telephony products, I knew the Cisco phones to be very capable fully featured units with a good quality noise and echo cancelling DSP based speakerphone. The phones are user-friendly and enable most operations to be completed using the context-sensitive soft keys next to the large LCD display, eliminating the need to remember cryptic numeric command strings associated with most PABX systems. This is what sets Cisco phones apart. Many phones cram too many functions into a tiny keypad and one-line display and expect the user to remember cryptic strings of numbers to do basic tasks like transfer a call. Most users don't bother. The Cisco 7900 phones sport a large display and use it to full advantage, walking the user through most operations. Cisco phones support advanced XML-based services enabling them to act as terminals for simple applications such as directory lookup and browsing of RSS feeds and we wanted our solution to support those features. Another important consideration was the ability to brand the phones with ring tones and a logo. Cisco IP phones are readily available both new and used/reconditioned as replacements and/or cheap alternatives and are popular within the asterisk community. We therefore began our quest with high expectations for the end user experience and that has influenced most of our subsequent decisions.
Cisco phones have certain infrastructure requirements, some of which are common to other IP phones and some of which are not. The phone is typically supplied preconfigured to work with Cisco Call Manager and requires a different firmware load to work with SIP protocol. They also require specific configuration files, bound to the phone’s MAC address. These configuration files must be created and stored on the network where they can be delivered using TFTP (Trivial File Transfer Protocol) at boot time. This requires TFTP, DNS and DHCP servers to be available to the phones. Ideally, the TFTP service would be incorporated in the telephony solution for best manageability, but the DHCP and DNS services would typically already be provided as part of an existing LAN infrastructure. DHCP is required to manage phone IP addresses and to supply other boot options such as the address of the TFTP server. This is critical to the deployment and provisioning process and without it each phone would have to be hand-configured, a time consuming and error-prone process. Then there are the advanced services, which require a back-end web server and custom web content to generate the necessary menus and screens. This all adds up to a powerful argument for adopting a system that directly and specifically supports the Cisco IP Phones.
We have evaluated Linux solutions based on Asterisk, and several of its derivative products, namely AsteriskNow, SwitchVox, TrixBox CE and TrixBox Pro. In addition I have considered Axon by NCH SwiftSound, which runs under Microsoft Windows. Commercial considerations aside, these are my technical findings.
Axon (NCH SwiftSound) runs on Microsoft Windows which makes it attractive from a manageability viewpoint, however support for specific devices is completely absent and Axon relies instead on generic protocol support. Axon provides support for SIP protocol and also has a Skype bridge, but it quickly became clear that it was not going to be easy to use with Cisco phones and was therefore not considered further.
Asterisk (Digium) is an open source product that is free to download and use. Of the remaining Linux based solutions, Asterisk is the underlying foundation and provides most of the functionality of all the other products. However, there is no direct support for endpoints (telephones) and everything must be configured by hand-editing the configuration files, of which there are many dozens. This requires detailed knowledge of telephony and the arcane macro syntax and sadly, as is typical with open source software, the standard of documentation is atrocious. I did not really feel that this was an easily supportable solution because of the complexity and poor standard of documentation. It would theoretically be possible to support the Cisco phones but it would be hard work to commission and maintain a system based on ‘vanilla’ Asterisk with anything other than a very small (<10) endpoints. The fact that it is a free product does not make up for that and it would be almost impossible for non-experts to understand and make changes to the settings. Whilst TiGra Networks would be capable of maintaining such a system, we did not feel that it was a solution we could package and recommend to our customers.
AsteriskNow (Digium) is largely obsoleted by SwitchVox and TrixBox. We did evaluate it but found it lacking in features and device support. We felt that there would be no point in adopting an obsolete solution and quickly dismissed it in favour of more recent alternatives.
SwitchVox (Digium) is a relatively recent introduction and adopts the philosophy of completely isolating the end user from the dozens of configuration files. All configuration is performed through a web-based GUI, which is professional and well implemented. This is at the opposite end of the spectrum from the base product Asterisk, where everything must be hand-edited.
This approach is not without merit. The fixed dial plan and user-friendly interface make it a very usable product while removing any temptation to hack the configuration files. The achillies’ heel is that you can’t do anything that hasn’t been built into the web GUI. There is no direct support for Cisco IP phones and although Digium claims that they will work in theory, we have not been able to obtain acceptable results. Furthermore, there is no support whatsoever for deployment and provisioning of endpoints or Cisco’s advanced services, which for a deployment of more than a few phones would be a serious limitation. If Digium were to add configuration and provisioning capabilities for Cisco phones, then this would be the best product of the bunch, but as of today the product is not really capable of supporting Cisco phones to our expectations.
TrixBox Pro (Fonality). Fonality’s enterprise (EE edition) and call centre (CC edition) offering is based on Asterisk with a proprietary configuration front-end. Fonality describes this as a ‘hybrid hosted solution’ and the configuration web application is hosted on Fonality’s servers. The actual hardware is on-premise for direct connection of trunks and extensions. The TrixBox Pro software establishes a VPN connection to Fonality’s configuration servers and all configuration and software updates are pushed from there.
Some specific types of telephone are directly supported by the management interface – but not Cisco IP phones. Once again, while they can probably be made to work, provisioning will be a challenge.
We were concerned about the management interface being hosted offsite. While there are pros and cons to this technique, if for any reason the control panel became unavailable then the box would no longer be configurable. That is an unacceptable risk to us. although in some situations we would certainly consider using TrixBox Pro for a customer installation.
TrixBox CE (Fonality).
We finally settled on TrixBox CE (Community Edition) because of its endpoint manager with direct support for Cisco IP phones. While far from polished, TrixBox’s endpoint manager was the only product to have any support at all for Cisco IP Phones and with a little experience it is a perfectly workable solution. The endpoint manager enables easy creation and editing of the required configuration files and provides TFTP support for provisioning the phones. The PBX itself is configured using the FreePBX web interface, but when necessary all of the configuration files are open for inspection and modification. There is also support for the Cisco advanced XML services which provides directory lookup. TrixBox CE supports all of the telephony features of the other variants and has the advantage of being free to download and use. Support is available from Fonality if required. TAPI support is provided through a client application – HUD Lite – which enables calls to be dialled directly from Microsoft Outlook and provides screen pop-ups upon incoming calls. For our purposes, TrixBox CE represents the best blend of features, device support, flexibility and price.