Category Archives: VOIP News

Read this before you pay $10 to Obihai for support

 

Notice
EDIT (May, 2018): FreePBX and Asterisk users that wish to continue using Google Voice after Google drops XMPP support should go here: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware.

As you may be aware, I removed all of the Obihai-related articles on this blog in protest of Obihai’s decision to attempt to charge users an additional $10 support fee in order to get firmware updates, and I no longer recommend Obihai devices. However, if you previously purchased an Obihai and find that you need to upgrade the firmware in order to continue using Google Voice, this Reddit thread explains how to do it without paying the $10. But before you do anything else, first try dialing * * * 6 from a phone that’s connected to your Obihai device, since you might be able to upgrade the firmware that way (although that’s not likely if you are still using username and password authentication for Google Voice). If that doesn’t work, try the instructions found here:

Read this before you pay $10 to Obihai for support (Reddit)
(Also posted at DSLReports: *** READ THIS before you pay $10 to Obihai for support ***)

The first post in the thread, from Reddit user Mango123456, reads as follows:

Obihai’s $10 support fee is optional. If you wish to avoid it, you can update your firmware manually to save the $10 support fee. This solves the May 2016 problem of Google Voice not working on OBi100/OBi110.

1a) If you have an OBi100/OBi110, follow the directions to update your firmware manually. Thanks to taoman54, rchandra, yorktown, and others who contributed to this.

1b) If you have an OBi200/OBi202, you can download the latest version of the 2xx firmware here (thanks taoman54).

2) If you cannot manually update your firmware because you do not know your OBi ATA’s admin password, follow the directions to factory reset your OBi ATA.

Please note: the links http://fw.obihai.com/OBi-latest.fw http://fw.obihai.com/OBi2-latest.fw are not the latest versions any more. At the time of this post, they are builds 2872 and 5110 respectively.

m.

Note that if you are reading this article after May, 2016 there might be newer versions of the firmware available (particularly for the OBi 200 series models) but after you have installed the correct firmware from one of the above links, you should be able to get any later firmware updates by dialing * * * 6 from a phone connected to the Obihai device.

EDIT (January/May 2018): Obihai has completely dropped support for the OBi100 and OBi110 models, and at some point Google Voice connectivity stopped working for some users. If you have such a device, you MAY be able to get Google Voice connectivity working again with Crowdsourced updates for Obihai ATAs and IP Phones. I have NOT tested these personally, so have no idea how well they work – they may restore full Google Voice connectivity to your OBi100 or OBi110, or they may turn it into a paperweight (hopefully not the latter, but I just don’t know, and I take no responsibility if it doesn’t work as intended). Obviously in this case it would not be prudent to pay Obihai for support, since they do not support those models anymore in any case, and would prefer you just buy a newer model despite the fact that the old ones usually continue to work perfectly well. And buying a new unit from Obihai really isn’t a solution either, since you don’t know if or when they will come out with yet a newer model and drop support for the current models. For more current information about alternative firmware for Obihai devices, see the ObiHAI Obi100/Obi110 Firmware Mod Discussion and/or the Obihai OBi200/202/302 + OBi1022/1032/1062 firmware mods thread at DSLReports. FreePBX and Asterisk users that wish to continue using Google Voice after Google drops XMPP support should go here: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware. (END EDIT.)

Why would you even need this? Well, the basic problem is that Google Voice (and all Google services really) have become very security-conscious lately, and if you or someone else tries to access your account in a way that Google doesn’t like, Google will force you to change your password, and your Obihai may stop working for Google Voice until you do. But once you change the password, the OBiTalk web configuration portal won’t allow you to change the Google Voice password on your Obihai device in the usual manner without paying the $10 extortion support fee to Obihai. There are two ways around that, one is to go into the Expert Configuration settings and change the password there (which doesn’t require payment, but the method for doing this might not be obvious to an Obihai user), and the other is to upgrade the Obihai firmware as described in the Reddit thread, in order to use oAuth authentication, which does not change if the Google account password changes. BUT, if you upgrade to oAuth you must to delete and recreate your Google Voice settings in the OBiTalk portal, but from then on you should not have any problems even if Google again requires you to change your password at some point in the future.

There are also persistent rumors, but they are still only rumors or more likely just speculation, that at some point Google Voice will stop allowing password authentication and force everyone to use oAuth, which would require the firmware update to be installed. However, that has not happened yet. Even if you aren’t ready to do a firmware upgrade now, you may want to download the firmware and save it someplace you can find it. You might want to do that just in case you ever do need to upgrade, and the links in that post are no longer working.

Link to forum thread: Obihai sucks – buyers paid for Google Voice, now they want more!

obihaisucks
Obihai now wants more money to give you the functionality you originally purchased!

This was kind of buried in a previous thread but I thought it deserved its own thread. I have been a supporter of Obihai devices in the past, but no longer! I have an Obihai OBi100 and when I first got it they were selling it with the idea of free connections to Google Voice, with no mention whatsoever of there being any possible future subscription fees. Anyway, today I went to see if I could add a Google Voice account to SP2 on my OBi100 and was greeted with the above screen.

At the time of purchase there was NO mention of needing to purchase technical support in order to keep using Google Voice, which after all was one of the advertised features and probably the primary reason anyone ever purchased an Obihai device. I have no issue with them charging extra to extend the warranty, but there’s nothing wrong with my device, other than that THEY require you to get new firmware before you can add a new Google Voice account or modify an existing one. In my book, this is extremely sleazy and is enough of a slap in the face that I would never consider purchasing another Obihai device.

If you read further down in the thread, you will see that technically-proficient users can still download the required firmware and install it manually (at your own risk) without paying the $10, but I don’t know how long that will last. The full thread is here:
Obihai sucks – buyers paid for Google Voice, now they want more! (DSLReports.com)

EDIT: Also see the post, Read this before you pay $10 to Obihai for support, which tells how to upgrade your Obihai without paying the extortion support fee.

EDIT 2: If you have an OBi100 or OBi110 device that is now considered “obsolete” by Obihai, and has stopped working with Google Voice, you MAY be able to get it working again with Crowdsourced updates for Obihai OBi100 and OBi110 ATAs. I have NOT tested this personally, so have no idea how well it works – it may restore full Google Voice connectivity to your OBi100 or OBi110, or it may turn it into a paperweight (hopefully not the latter, but I just don’t know, and I take no responsibility if it doesn’t work as intended). See the thread Obihai OBi200/202/302 + OBi1022/1032/1062 firmware mods for additional information on available third-party firmware for Obihai devices. Obihai apparently does NOT want people to know that this alternative firmware exists, and has allegedly banned users that so much as mention the existence of this firmware in their forums.

EDIT 3: There are once again many posts on various VoIP forums suggesting that Google Voice will end the use of XMPP protocol in mid-June, 2018. For information on that, I urge you to follow this thread on DSLReports.com: Google Voice XMPP support will go away in June. FreePBX and Asterisk users that wish to continue using Google Voice after Google drops XMPP support should go here: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware.

I had formerly hosted several how-to articles about the Obihai devices on this forum, that I had obtained permission from the author to repost when the old Michigan Telephone blog went defunct, but because of this action by Obihai I have taken those articles offline because I don’t want to appear to be encouraging anyone to purchase an Obihai device, or to be providing any kind of support for them. Many of those articles were rather dated anyway, but if anyone really misses them I could possibly put one or more of them back up, but with a suitable disclaimer, or if you have a URL for one of those old articles you could try accessing it via the Wayback Machine. However, at this point I emphatically DO NOT RECOMMEND the purchase of an Obihai device by anyone.

Black Friday deal on Vestalink VoIP (internet phone) service

Got an email today saying that from now through November 30 you can save 40% on all Vestalink service plans, if you use the promo code: blackfriday

Since Vestalink is one of the lower-priced VoIP providers anyway, this might be a particularly good deal for those looking for inexpensive VoIP service for yourself or a family member.

This comes with the standard caveat that although I am passing this along, I cannot make any guarantees about this company or the services they offer, so read all the terms and conditions and decide for yourself whether you feel that this is a service worth trying.

Vestalink (don’t forget to use the promo code blackfriday)!

Security alert for users of the FreePBX Distro

We do not normally provide security alerts but since we have several articles on this site dealing with tweaks to Asterisk and FreePBX, we thought we would just pass this along. If you are a FreePBX Distro user, go read this thread and this security notice now. You should particularly do this if you are noticing high CPU usage.

The problem is that there is an exploit in the FreePBX Distro caused by a piece of software that turns itself on when installed. Some users want it, but many have never heard of it and don’t use it, so it should be turned off by default. One side effect of this software is that it has given attackers a way to install and run bitcoin mining software on affected PBX’s, which can degrade performance and increase power consumption. It’s a simple fix to keep this from happening, so do it now!

Not such a great deal on a VoIP PBX?

Is this the worst deal ever on a VoIP PBX? Probably not, but in our opinion it’s certainly not the best deal by a long shot, unless maybe they are providing a GREAT support package. See this thread on the PBX in a Flash forum. Interesting that their ad says “All products are sold on a No Return Basis.”

In case you’re not quite getting the picture, we’ll point you to this totally unrelated article. 😉 Compare what you see there with what’s pictured in the ad at the above link. We cannot know for sure that the innards of that ~$350 PBX are actually a ~$35 Raspberry Pi, at least not unless someone purchases one and disassembles it to find out, but you can definitely spot some similarities in the placement of the various input/output ports.

Rather than purchase any device costing a few hundred dollars on a “No Return Basis”, you might want to consider just getting a Raspberry Pi and using one of the distributions mentioned in our article, Asterisk on a Raspberry Pi – which distribution is best?. Even if you don’t agree with our conclusions in that article, any of the distributions mentioned there would probably be a better choice in the long run. But, that is just our opinion.

Link: The SIPaholic’s Dream Come True: Introducing Anveo Direct SIP Trunking

We’re incredibly happy with the current list of providers that we recommend to PBX in a Flash™ users for VoIP trunking. At the top of our list is Vitelity, a leading VoIP provider that has been a major contributor to the Nerd Vittles and PBX in a Flash projects for many years. But, as often happens, one of our gurus on the PIAF Forum comes up with a terrific discovery that we just can’t wait to pass along. This week it was @w1ve who stumbled upon a new Anveo® Direct service for end-users with a special DID and SIP trunk offer. While the sub-account flexibility of Vitelity and some of the other providers is sorely missing, Anveo Direct does provide end-users with many of the same routing tools and SIP feature set that previously were reserved for use by major carriers. If you don’t believe some of the competition is less than thrilled, read this message thread on dslreports.com. And, until June 1, you can order DIDs in almost any U.S. region for 50¢ a month per DID with no setup fee. With Anveo Direct Value, that 50¢ buys you two trunks with 400 free incoming minutes a day. Outbound calls are pay-as-you-go and vary depending upon where you’re calling. Typical U.S. rates are $.001 to $.0055 per minute with least cost routing and automatic failover when a particular carrier’s route is having problems. …..

Full article here:
The SIPaholic’s Dream Come True: Introducing Anveo Direct SIP Trunking (Nerd Vittles)

Link: FreePBX security advisory – SIP extension types

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
We can set defaults for all these, so why not extension type?

We can set defaults for all these, so why not extension type?

The SysAdminMan blog has posted a new article related to FreePBX security, that I strongly urge you to read if you are running FreePBX or any FreePBX-based distribution:

FreePBX security advisory – SIP extension types

The basic issue is that by default, FreePBX sets extensions to type=friend rather than the more secure type=peer.  The article says it’s for historical reasons but I suspect there have been other reasons at play here (pure stubbornness, perhaps?).  But with the growing body of evidence that type=friend is bad, and because FreePBX now has an Advanced Settings module that allows you to to change certain defaults (though not yet this one), I have put in a Feature Request asking that system administrators be allowed to select a default type for extensions.  We’ll see if it goes anywhere (and it might help if anyone who supports this idea would add a comment to that ticket), but given that in the past they’ve been reluctant to even entertain the idea of changing the default, I fear that they may once again refuse to even consider it.  And for those of us who want to keep our systems as secure as reasonably possible, that would be a real shame.

Geolock — a Perl script for Asterisk or FreePBX users to enhance security

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

I created the following Perl script and have been running it for a week or so, and it seems to be working well.  The idea is that this script runs once per minute, and whenever a SIP or IAX extension is registered with your Asterisk system the script looks at the IP address that the extension is registering from, and if that address is outside your home country (the United States by default), the IP address is immediately banned using IPtables.  So, your remote extensions could be anywhere in your home country and connect to your system, but if a hacker from some other nation penetrates your system and somehow guesses one of your passwords, they will (in theory) have less than a minute to do any damage before they are banned. And once they are banned, the rightful user of that extension should still have no difficulty connecting, as long as they are not coming in from outside your home country.

For those of you that don’t have any extensions connecting from outside your home country, consider this another tool in your arsenal of defenses against intrusions.  Combine it with strong passwords, and Fail2Ban with IPtables for additional security.

NOTE THAT THIS SCRIPT IS NOT GUARANTEED TO DO ANYTHING AT ALL, other than take up space on your computer.  IT SHOULD STILL BE CONSIDERED EXPERIMENTAL until there has been more testing on it.  I believe it works properly, but have no way to do extreme testing on it to see if or how it might break. THERE IS NO WARRANTY OF ANY KIND!!!

Prerequisite: Obviously, you must have IPtables installed and functioning properly, and you must install either the Geo::IP or Geo::IP::PurePerl Perl module (do NOT install both!). You can install one of these using Webmin (using Webmin’s Others | Perl modules page), or in any other way you usually install Perl modules (e.g. CPAN). The difference between the two was explained in my original article, as follows:

… there is a Perl module called Geo::IP, which calls the GeoIP C API. If you install that API (when downloading, I’d go into the test/ directory and get the latest beta) using the directions on the linked page, and then install the Perl module (you must do it in that order, or installation of the Perl module will fail), you could run a Perl script that shows the location that your off-site extensions are coming in from. If you don’t want to install the API, or can’t figure out how (not difficult if you follow the directions), you can use the Geo::IP::PurePerl Module which is slower, but does not require the additional C library. Just so you know, GeoIP puts its data file at /usr/local/share/GeoIP/GeoIPCity.dat and they suggest that you go to http://www.maxmind.com/download/geoip/database/ every month or so to grab the latest database (the full link for the country database is currently http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz or you can get a much larger city-level database at http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz — just make sure you don’t grab a CSV version by mistake!). If you need them, there are installation instructions for the database, although they are primarily for the city-level database. If you buy an account, they’ll give you automatic updates, though I can’t imagine it would be that hard to write a script to do that (or maybe Google could help you find one, or see this message thread).

If the above is confusing to you, I’d stick with the Geo::IP::PurePerl Module. That should at least get you going. You also need the Perl Sys::Syslog module (unless you want to omit all the syslog-related instructions), though chances are you may already have that one.

Now, here is the Perl script. I called it geolock.pl (although you are free to name it whatever you want), and I put it in the /var/lib/asterisk/agi-bin/ directory and made it executable. Note this is in a code block so the long lines will overflow the column width, so you need to copy and paste this into a text editor. Also there are certain lines you will need to change, as explained below:

#!/usr/bin/perl
use strict;
use warnings;
use Geo::IP;
use Sys::Syslog;
my $gi = Geo::IP->new(GEOIP_STANDARD);
my ($ext, @peerline, @extension, $ipaddress, $country, $shellcmd);
my $flag = 0;

my @sippeers = `asterisk -rx "sip show peers" | grep -v 192.168.0. | grep ^[1-9] | grep -v "(Unspecified)" | grep / | sort -n`;
# change grep statements in above line to match your local IP range (1st grep) and first digits of extensions (2nd grep)
foreach (@sippeers) {
@peerline = split(" ");
$ipaddress = $peerline[1];
$country = $gi->country_code_by_name($ipaddress);
@extension = split("/",$peerline[0]);
$ext = $extension[0];
#    print "Extension $ext has IP address $ipaddress which is in country $countryn";
if ($country && $country ne 'US') {
$shellcmd = `iptables -D INPUT -p ALL -s $ipaddress -j DROP 2>&1`;
system("iptables -A INPUT -p ALL -s $ipaddress -j DROP");
openlog($0,'pid','user');
syslog('notice', "Banning IP address $ipaddress in $country because Asterisk SIP Extension $ext is connecting from there");
closelog;
if (index($shellcmd, "Bad rule") >= 0) {
$shellcmd = 'echo "This is an automated message - please do not reply. IP address ' . $ipaddress . ' in country ' . $country . ' was banned in iptables because Asterisk SIP extension ' . $ext . ' was connecting from there." | mail -s "IP address banned on Asterisk box" root@localhost';
system($shellcmd);
$flag = 1;
}
}
}

### INCLUDE THIS NEXT SECTION ONLY IF YOU HAVE IAX2 EXTENSIONS ###
my @iaxpeers = `asterisk -rx "iax2 show peers" | grep -v 192.168.0. | grep ^[1-9] | grep -v "(Unspecified)" | grep -v "iax2 peers" | sort -n`;
# change grep statements in above line to match your local IP range (1st grep) and first digits of extensions (2nd grep)
foreach (@iaxpeers) {
@peerline = split(" ");
$ipaddress = $peerline[1];
$country = $gi->country_code_by_name($ipaddress);
$ext = $peerline[0];
#    print "Extension $ext has IP address $ipaddress which is in country $countryn";
if ($country && $country ne 'US') {
$shellcmd = `iptables -D INPUT -p ALL -s $ipaddress -j DROP 2>&1`;
system("iptables -A INPUT -p ALL -s $ipaddress -j DROP");
openlog($0,'pid','user');
syslog('notice', "Banning IP address $ipaddress in $country because Asterisk IAX2 Extension $ext is connecting from there");
closelog;
if (index($shellcmd, "Bad rule") >= 0) {
$shellcmd = 'echo "This is an automated message - please do not reply. IP address ' . $ipaddress . ' in country ' . $country . ' was banned in iptables because Asterisk IAX2 extension ' . $ext . ' was connecting from there." | mail -s "IP address banned on Asterisk box"
root@localhost';
system($shellcmd);
$flag = 1;
}
}
}
### END OF SECTION ONLY NEEDED IF YOU HAVE IAX2 EXTENSIONS ###

if ($flag == 1) {
`asterisk -rx "restart now"`;
}
else {
openlog($0,'pid','user');
syslog('info', "Completed normally");
closelog;
}

These are the things you need to change for your local installation:

  • If you used the Geo::IP::PurePerl module then be sure to change the two references to Geo::IP to Geo::IP::PurePerl.
  • Remove the optional section for IAX2 extensions if you don’t have any of those (but keep it if you have any IAX2 extensions, even if they are only internal ones).
  • In the line(s) “if ($country && $country ne ‘US’) {” change US to the code for your home country if you are somewhere else in the world. You could also create a more expansive conditional statement here to allow multiple countries, or a more restrictive ones if you want to block an IP that doesn’t resolve to any country (I consider that a database error, but maybe you don’t). If you have installed the city-level database, you could even (in theory) test for something other than country, such as a state or province, city, time zone, ISP, etc. This line appears in the SIP section and also the optional IAX2 section, so make sure you change both lines if necessary.
  • There are two instances of root@localhost in the above script (in the SIP section and also the optional IAX2 section), which you should change to a valid e-mail address if you want to receive e-mail notifications when an IP address is banned. If you don’t want to receive such e-mail notifications, then comment out or remove those two lines in their entirety (they start with: $shellcmd = ‘echo “This is an automated message …) and also remove the following system($shellcmd); line(s).

The following apply to the two lines that begin with "my @sippeers” and, in the optional IAX2 section, “my @iaxpeers”:

  • Change “grep -v 192.168.0.” to a regular expression or pattern that will match it IP address of all extensions on your local network.  The pattern as shown works if all your local extensions will be in the range 192.168.0.x. Since you can use a regular expression, you could do something like “grep -v 192.168.[1-5].” which would match any local address from 192.168.1.0 through 192.168.5.255.
  • Change grep ^[1-9] to match the first digit of your extensions – as shown, anything starting with a digit 1 through 9 would be considered an extension.  The idea here is that we only want to look at extensions, not trunks (which you can restrict using permit and deny statements, if necessary). Most trunks don’t begin with a number (when you do a “sip show peers” or “iax2 show peers” listing from the CLI), so this is what separates extensions from trunks.  You may have to get a bit more creative if you have a trunk that starts with a number that overlaps your extensions. If you run the entire section between the backticks (the ` characters) from a Linux command prompt,  it should show you all of your connected non-local (that is, not on your internal network) SIP or IAX extensions (depending on which line you run), but no trunks, local extensions, offline extensions, or header information.

Sharp-eyed readers may observe that I first try to delete an iptables rule before creating it.  That’s because I don’t want to create the same rule multiple times (iptables happily accepts duplicates, unfortunately).  If I get an error when trying to delete the rule, then I know that what follows will be the first attempt to create it, and I should send an e-mail and restart Asterisk when we’re all finished.  Basically, it’s supposed to be a safety mechanism to keep from repeatedly sending the same e-mail, or restarting Asterisk once a minute if for some reason the iptables rule doesn’t “take” at first.

Again, don’t forget to make the Perl script executable, and run it manually a few times to watch the output (uncomment the commented-out “print” lines during initial testing – you can remove them once you are satisfied it’s working as it should be).  After you have run it a few times, from the Linux command prompt do iptables –list and make sure everything looks okay there.

One thing you should be aware of is that when this script detects an intrusion attempt (a connection from outside the United States), after it bans the IP address it restarts Asterisk, which will interrupt any calls in progress.  That’s deliberate; I assume you want to throw the hackers off your system right now, even if it means your users may have to re-dial their calls. Howerver, if for some reason you don’t want to do that, then you can change the line `asterisk -rx “restart now”`; to `asterisk -rx “restart when convenient”`;, which will wait until there is no usage on your system to restart Asterisk.  In that case, good luck to you if the hacker just placed a call to some $100-a-minute destination! In theory IPtables will interrupt the conversation (no audio will pass) BUT that does not mean Asterisk will tear the call down right away – when an extension “just disappears”, Asterisk tends to wait a LONG time to see if it will come back, and if it never does, well that’s what we call a “zombie” call — it just won’t die (at least not until the other end disconnects)! EDIT: If you don’t want to restart the whole system but do want to throw the hacker off NOW, see the modification by “Florent” in the comments below — I have NOT tested his changes personally, but they may do what you want.

The final step is to make this execute once a minute.  I used Webmin’s “System | Scheduled Cron Jobs” to set this up:

cron job setup using WebminBut if you are more comfortable creating a cron job from the command line, by all means, feel free to do so.

Finally, I always say that suggestions for improvement are welcome, and also, if you want to translate this into some other programming language, you have my blessing. Please be sure to test it thoroughly before relying on it, because if someone manages to hack through anyway, I’m not going to pay your phone bill! Once again, the above should be considered experimental code and is not guaranteed to do anything at all.

Review of Building Enterprise Ready Telephony Systems with sipXecs 4.0 by Michael W. Picher (Packt Publishing)

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog. In order to comply with Federal Trade Commission regulations, I am disclosing that he received a free product sample of the item under review prior to writing the review, and that any links to Amazon.com in this article are affiliate links, and if you make a purchase through one of those links I will receive a small commission on the sale.

This article was originally published in December, 2009.

Cover of Building Enterprise Ready Telephony Systems with sipXecs 4.0

Cover of Building Enterprise Ready Telephony Systems with sipXecs 4.0

Regular readers of this blog may recall that I recently reviewed another Packt Publishing book, FreePBX 2.5 Powerful Telephony Solutions by Alex Robar, and that my review was generally positive.  However, I have wondered for a while if there was going to be any serious competition for Asterisk and FreePBX that would also be open source, and freely available to anyone that cares to download it.  Well, this book discusses one contender – sipXecs by SIPfoundry.  You can look over their web site to get some idea of what sipXecs is, but in one respect it’s along the same lines as FreePBX, in that it provides a web-based GUI that allows you to do all the work of configuring your phone system from any web browser.  The book is called Building Enterprise Ready Telephony Systems with sipXecs 4.0 by Michael W. Picher.

I’ve never personally so much as laid eyes upon a working sipXecs installation, so this isn’t going to be a review of sipXecs per se.  But I suppose some are wondering what the difference is between sipXecs and FreePBX.  The impression I got from reading this book is that the two have some differences in features, and even where there is feature overlap, there are differences in the way those features are implemented.  If you are just counting features, FreePBX probably offers more, and many of those features have more configuration options.  FreePBX would probably work very well in a home or small office.  sipXecs, on the other hand, seems to have been designed by folks with experience in networking and larger business installations.  If you were trying to link several branches of a medium-sized to large corporation together, and it’s crucial to have 100% uptime (or as close to that figure as possible), sipXecs might be a better choice (at least until someone high in the corporate food chain demands a feature it doesn’t offer).  And if you’re a networking professional, you might find sipXecs more appealing.  This is definitely NOT to say that sipXecs could not be used in a home or small office setting, nor that FreePBX could not be used in a large corporation for that matter, just that each may fill a particular niche better than the other.

So I will concentrate on the book itself, and I’ll let the publisher have the first word.  Here is how they describe this book:

A clear and concise approach to building a communications system for any organization with the open source sipX Enterprise Communications Server

In Detail

Open source telephony systems are making big waves in the communications industry. Moving your organization from a lab environment to production system can seem like a daunting and inherently risky proposition. Building Enterprise Ready Telephony Systems with sipXecs delivers proven techniques for deploying reliable and robust communications systems.

Building Enterprise Ready Telephony Systems with sipXecs provides a guiding hand in planning, building and migrating a corporate communications system to the open source sipXecs SIP PBX platform. Following this step-by-step guide makes normally complex tasks, such as migrating your existing communication system to VOIP and deploying phones, easy. Imagine how good you’ll feel when you have a complete, enterprise ready telephony system at work in your business.

Planning a communications system for any size of network can seem an overwhelmingly complicated task. Deploying a robust and reliable communications system may seem even harder. This book will start by helping you understand the nuts and bolts of a Voice over IP Telephony system. The base knowledge gained is then built upon with system design and product selection. Soon you will be able to implement, utilize and maintain a communications system with sipXecs. Many screen-shots and diagrams help to illustrate and make simple what can otherwise be a complex undertaking. It’s easy to build an enterprise ready telephony system when you follow this helpful, straightforward guide.

What you will learn from this book

• Understand the complexities of an IP Telephony and Voice over IP network
• Build a clear process for migrating existing phone systems to an IP based system
• Deliver a solid foundation for any IP based phone system
• Quickly and easily get a sipXecs open source PBX running
• Deploy phones quickly and easily.
• Utilize Internet Telephony Service Providers to reduce monthly telephony bills
• Develop training materials to help successfully teach your users how to use the system
• Leverage sipXecs Automatic Call Distribution Queues to handle basic Call Center needs
• Operate and Maintain a reliable communications platform

Approach

This book was written to be a step by step approach to building a communications system for any organization. Care was taken to clearly illustrate with diagrams and screen shots all of the steps and concepts along the way. [Emphasis added – I’ll have more to say on that point!]

Who this book is written for

This book is written for network engineers who have been asked to deploy and maintain communications systems for their organizations.

And here’s the chapter list:

Preface
Chapter 1: Introduction to Telephony Concepts and sipXecs
Chapter 2: System Planning and Equipment Selection
Chapter 3: Installing sipXecs
Chapter 4: Configuring Users
Chapter 5: Configuring Phones in sipXecs
Chapter 6: Connecting to the World with sipXecs
Chapter 7: Configuring sipXecs Server Features
Chapter 8: Using sipXecs—The User Perspective
Chapter 9: Configuring Advanced sipXecs Features
Chapter 10: Utilizing the sipXecs ACD Service
Chapter 11: Maintenance and Security
Appendix: Glossary
Index

See the Table of Contents page to get a more detailed chapter breakdown.

Now, when I review a book, the thing I am looking at is whether the author accomplishes what he or she set out to do.  In this case, the intent of the book is to instruct someone in how to set up a working sipXecs PBX.  So, I look at whether the author seems to have a good grasp of his subject matter, and whether he can communicate his knowledge to the reader in a clear and understandable manner.   A third consideration is whether the book is a good value for the money.   Technical books often aren’t inexpensive, so I tend to mark them down if I perceive that there’s a lot of “filler” material in the book.

It’s difficult for me to decide how to rate this book.  Does the author understand his subject matter?  Yes, it certainly appears that he does.  Does he effectively communicate it?  Yes, the book was an easy read — I really didn’t feel like I was in “over my head” at any point in the book.  Could you set up a working sipXecs phone system after reading this book?  I think I could, but I can’t speak for anyone else.  In fact, in many ways, this was one of the clearest and most understandable technical books I’ve read.

You sense a “but” coming, don’t you?

Well, there is, and it’s a big one.  Did you notice above where the publisher said that “Care was taken to clearly illustrate with diagrams and screen shots all of the steps and concepts along the way”?  Well, the book definitely contains screenshots — a LOT of screenshots.  And normally, that would be very good thing, because as the saying goes, a picture is worth a thousand words.  A screenshot would not add value to a book only in the case where it was useless “filler” material, and it’s pretty apparent that none of the screenshots in this book were intended to just be “filler.”

But, for a screenshot to be useful and not “filler”, it has to be readable.  And in that regard, this book has a serious problem.   If you buy the hardcopy edition of the book, I’d strongly urge you to also buy a good magnifying glass, because you’re going to need it to get anything out of those screenshots, unless perhaps you have perfect vision.   Apparently the author (or whoever took the screenshots) has a widescreen monitor, and was running their web browser in full screen (or at least full width) mode.   As a result, most of the text in the screenshots borders on microscopic, and some of the smaller print is unreadable (by me, anyway).   When you take those extra-wide screenshots and reduce them to about five inches in width on a printed page, you need very good eyes (or good glasses) to make out the text.  After trying to decipher the details in those screenshots for a while, I started to get a headache!

At first I thought maybe it was my eyes going bad — I am getting older, after all — but then I opened up some of the other books I have in my collection, including other Packt Publishing books, and none of them suffer from this problem.  Frankly, if I were the publisher I’d stop the presses on this book immediately, and not let another copy go out the door until all the screenshots were re-done, but then that’s just me.

Now, that said, the book is not totally without value.  I think that perhaps the author just might have realized he had a problem, because in many cases he repeats in the text most of what’s in the screenshot (at least the portion to which he’s calling your attention), so not being able to actually read the screenshot isn’t always such a loss — but unfortunately, it also relegates the screenshots more toward the category of “filler.”

So, would I recommend this book? Yes, for two classes of readers in particular:

  • Those thinking about setting up an Asterisk/FreePBX system that would like to know about available alternatives.  It may be that the particular combination of features that you deem essential can only be found in one of either sipXecs or FreePBX, and by reading this book and the aforementioned FreePBX book, you’d have a pretty good idea of the differences in capabilities between the two.
  • Those thinking of installing a VoIP PBX in a larger organization, where reliability and scalability are far more important than the actual feature set.   My impression from the book is that sipXecs is designed with larger businesses and higher call volumes in mind.   That’s no reason that someone with a small business should shy away from it, but if you are very concerned about reliability and high “uptime” then you probably should at least give sipXecs some consideration.  And if your organization is large enough to have people with degrees in computer networking in your employ, they might prefer working with sipXecs.  This is not to say you can’t do a large installation using Asterisk, but now you have another choice, and this book can help you decide which is best in your particular situation.

If it weren’t for the screenshot issue, I’d be giving this book very high marks.  The focus of the book is deployment in a business setting, and the author takes you through the steps for planning and implementing the system, whether you are replacing an existing PBX or starting from scratch.  Having some knowledge of computer networking would be helpful, but as I noted, I’m no networking expert and yet I didn’t feel totally lost.  In fact, if you know telephone systems but don’t know all that much about networking, you’ll find that just about everything you really need to know is explained, but without going into extraneous detail.  You get the information you need to get the job done, but if you want to become a networking guru, you’ll need some other book for that.

I’m just really sorry that the bad screenshots marred an otherwise fine book, but I have to call ’em as I see ’em, and in my opinion they really are that bad.  Whether that would matter to you is something only you can decide.  I should mention that I was provided a hardcopy edition of the book for review, but Packt also offers an e-book edition in Adobe PDF format on their web site, and if you are comfortable reading e-books, I’d definitely go that route with this book, because most PDF readers will let you magnify sections of a page.  So, the nearly unreadable screenshots might actually be very readable in the e-book edition. Also, if you do go the e-book route, be sure to scroll down the page and look for the offer, “Buy this eBook with FreePBX 2.5 Powerful Telephony Solutions eBook and get 50% discount on both. Just enter sip40xecs in the ‘Promotion Code’.”  Seems like a good deal, especially if you’re wanting to compare FreePBX and sipXecs.

Building Enterprise Ready Telephony Systems with sipXecs 4.0 by Michael W. Picher (Packt Publishing link) (Amazon affiliate link)