Wednesday, 21 March 2012
Later, we started selling Network Alchemy PABXs which were a larger scale, and we sold systems with ISDN30 lines and hundreds of phones in large offices. We kitted out call centres. One of the small models was even on display in the science museum, thanks to us. We did a load of support software and sold boxes to do voicemail and call logging and billing. We led the way in integrating the phone systems and management tools. We even moved on to selling Splicecom phone systems.
I always wanted to make my own ISDN PABX though - as no system quite did what I wanted in terms of features. There was always something that was a compromise.
We gradually moved over in to Internet stuff over a few years, partly because the Network Alchemy did ISDN "dial-up" Internet access as a standard feature.
Since then we have started doing VoIP services, so you can have a phone on your desk with a phone number connected via the Internet. These systems are tricky when people have NAT and they are not playing IPv6 very well yet, so this is not ideal. But it works and we have thousands of VoIP customers. But this is not quite the same as the old "phone systems" we used to sell.
As of today we have a FireBrick acting as an Internet gateway and SIP gateway. Yes, much work to do but it sort of hit me that it is finally my chance to make a PABX.
What you probably don't realise is that I first started playing with PABXs on a 1 line 5 extension analogue system which I had at home and at my parents (IIRC) over 20 years ago. There was a 2 line analogue system as well, I seem to recall.
The design is very much a "per packet" system, and the FireBrick has no hard disk, so handling calls is fine but not IVR, voicemail or call recording. However, it can easily link to services "in the cloud" for such things and stand alone software on a local PC/server as well.
Ironically, a lot of features and "state" are now in the phones. e.g. Do not disturb, call forward, divert on no reply, etc. But the call server needs to handle ring groups and call queuing systems. It can handle things like "wrap up time". With the SNOM phone we can do busy lamp fields as well. And one of my favourite features "call steal" which is so much easier than transferring calls.
Of course the FireBrick can easily provide data on calls, queue times, and so on.
So, my plan is to make the FB2500/FB2700 provide a good set of PABX features. Obviously we like the SNOM phones, but it will be nice to integrate nicely with other makes of phone too. We will start using it ourselves in our offices when we are ready, which will mean it will get new features quickly.
I am also inclined to make it a standard feature in the base model. This is not definite yet, and maybe you will need a "fully loaded" brick for all of the features. To be decided.
Of course it will integrate well with our services. We will be able to have a small office, even if using NAT, with phones on desks and real phone numbers through us. We can have iPads L2TP in to the office LAN, and have mobile phone SIMs connect as office PABX extensions. I think it will be very cool.
P.S. please don't tell me that a multi decade long ambition to make a PABX from scratch is somehow "sad".