I have never really gone looking for a book such as this, as in most circumstances when we need support I look on google or call our IT support company.  In this respect I dont know what the competition is for a Trixbox support book, but I get the impression that this is a ‘first’.

Overall, I really liked the book, as it uses plain language that a non sys admin can understand to explain what Trixbox is, what it isnt , and how to install, configure and trouble shoot it.  There are simple explanation of lots of functions that I have learnt about the hard way in here, and having read the book, I wish that I had done so before configuring it myself, as it would have saved lots of time, probably about 10 hours of iterative learning.  In this respect, for £28 its very good value. When you put this in the context of the cost of a traditional small business phone system at £5K-£20K – its amazing value as trixbox is of course free and open source.

There are some problems that you just wont solve by using this book and non experienced sys admin.  The major IP network range problem we had that nearly destroyed our migration is not even mentioned in the book .

So, my advice is to buy this book to learn if Trixbox is for you, or if you want to learn how to configure a working system.  Its not going to solve all your installation problems like that mentoned above or instaling ISDN cards, but its a start. It will be a very useful reference for us moving forward – I’m now off to try the direct fax to PDF feature I didnt even know existed now that I’ve read the book!

Its available from here.

Disclosure: I’ve been given a free copy of the book to review and keep, but am under no other pressure or commercial interest in respect of this book.

• very poor call quality, so bad we were often told to “get out of the dustbin” and we sounded like daleks
• Calls cut of in the middle of a conversation
• Calls to a group were notifying to the SNOM hard phones in the group upto 10 seconds before the softphones, making it very difficult to identify calls
• SNOM M3 DECT SIP phones didnt work, but SNOM 300 hard phones did. Sometimes.
• Call handling using Hudlite was not integrated with Ekiga (or anything), and so it was very hard for users to forward calls around the office, and many, many calls were missed as there is no way to notify users of an incoming call if the ekiga box is minimised.
• the system often had network problems, such that we replaced the ADSL router and moved the DHCP function several times in a month to get some sort of stability.  Last week alone, we lost about 6 working hours of the working week with no phone system (yes, no phones at all).

By the end of the 4th week, morale was pretty poor, and after a crisis meeting we decide to do 2 significant changes.

1) bring in Matt and Dave, both sys admin type people from our open source support consultancy Senokian on a “do not leave until you have fixed it” mission to find out what was wrong with our setup.

2) abandon the softphone system – hudlite and a SIP client (like ekiga) it is just not good enough for a business environment; we bought a new batch to SNOM 300 hard phones for all the previous softphone users.

Very satisfactorily, a major trixbox/network fault was found by the superb Senokian chaps, and fixed, and after that all the new hard phones worked perfectly.  That was friday.  After a very frustrating period, we should have a much more stable week this week, but have leant some lessons that others may wish to heed in due course.

1. The Hudlite system built into trixbox is difficult to work, and we do not recommend it for busienss use.  It desperately needs an inbulit SIP client, and is almost unusable without such a  development.  We know this, becuase we used a SWYX VOIP phone system that was so integrated for 4 years before trixbox.
2. If you have the same symptoms as us, then check your trixbox setup, so that it has the right local network subnet mask, or else, as we found, if you use an incorrect one (probaly the default), all the network traffic tries to go via your  network router (ADSL in our case), and it dies with the repeat NAT and repeat boucing of packets.  In our case, it was set as (i think) 127.0.0.1, and it should have been 192.x.x.x etc.

I hope this post helps someone.  I will report back after a few days on what we experienced this week, but it looks good.  Just dont make our mistake, and try to use Hudlite softphones for a business critical operation ie a working phone system.

It may be a conincidence with the snow and bad weather this week, but the disruption to our operations has been very significant, resulting in the one of the lowest level of sales against target in my memory.

This is a profit warning to businesses – unreliable phone systems hurt.

The process we used was such:

1. I attended an open advantage awareness/training course on trixbox to see what it could do.
2. I engaged senokian to buy a basic DELL PC and install Trixbox on it with an ISDN BRI card
3. I configured it using the great notes freepbx.org and  trixbox.org , copying the settings from our SWYX voip system
4. Dave from Senokian ironed out 2 bugs in the setup relating to our configuration of ISDN card and email settings for voicemail.
5. I tested it, opened some ports to enable remote SIP access on trixbox and tweaked it.
6. It works, and is ready for rollout.

In terms of SIP clients, I’ve settled on Ekiga / Hudlite for linux, and openwengo /hudlite for windows (all soon to be gone) anyway.

So, we have a working trixbox phone system ready to rollout.  Another milestone in our open source migration bites the dust.