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.
Cover of FreeSWITCH 1.0.6
In case you’ve never heard of FreeSWITCH, it is a “telephony software engine”, which means it’s in the same category as Asterisk. Over the years I’ve noticed that some Asterisk users have become frustrated with Asterisk due to unfixed bugs and design flaws that mean that the software doesn’t always work as it should. So, for quite some time, I’d hoped that a viable alternative to Asterisk might emerge, if only to keep the Asterisk developers on their toes. Competition between software projects tends to be a healthy thing, and from what I’ve read in this book, it appears that FreeSWITCH just may be the software product that eventually replaces Asterisk as the #1 open source telephony software engine.
Before I begin, as is my custom with such reviews, let’s start with a quick overview of what’s in each chapter (for the complete Table of Contents, see the Packt Publishing web site):
Preface
Chapter 1: Architecture of FreeSWITCH – includes notes on the FreeSWITCH design and important modules
Chapter 2: Building and Installation – how to build and run FreeSWITCH under Linux/Unix, Mac OS X, or Windows
Chapter 3: Test Driving the Default Configuration – here you learn how to control FreeSWITCH with the CLI and to make your first call
Chapter 4: SIP and the User Directory – includes adding users, setting up voicemail, and setting up a gateway to connect to the world (link is to sample chapter in PDF format at the Packt Publishing site)
Chapter 5: Understanding the XML Dialplan – this gets into the “meat” of FreeSWITCH dialplan creation
Chapter 6: Using the Built-in XML IVR Engine – here’s where you learn one way to build an IVR (auto-attendant)
Chapter 7: Building IVR Applications with Lua – really an example of using a scripting language with FreeSWITCH. A few other languages are supported
Chapter 8: Advanced Dialplan Concepts – if Chapter 5 was the hamburger, this is the sirloin
Chapter 9: Controlling FreeSWITCH Externally – explains the event system architecture, and how to read and send events
Chapter 10: Advanced Features and Further Reading – includes multi-user conferencing, billing, XML/Curl, alternative endpoints, and configuration tools and related projects
Set up a basic system to make and receive phone calls, make calls between extensions, and utilize basic PBX functionality
Avoid common implementation mistakes and deploy various features of this telephony system with best practices and expert tips
Perform routine maintenance for smooth running and troubleshoot the system when things are not going right
Apply regular expressions to unlock unique and powerful call routing scenarios
Call your own application(s) when particular events occur and control FreeSWITCH using the powerful Event Socket
Set up multi-party conferencing facilities for your system
Interact with callers, gather information, and route calls to the appropriate recipient using the automated, built-in XML IVR (Interactive Voice Response) engine
Create a flexible dialplan, and allow third-party tools to be quickly and easily created using dialplan parsers other than the default XML Dialplan
Park multiple calls in a FIFO queue and unpark them in the order in which they were received, using the mod_fifo module
Record an entire phone call or session using the call recording feature
Create advanced call control applications with the Lua scripting language
Take a peek into the vibrant online community and history of FreeSWITCH
Approach
This book is a step-by-step tutorial with clear instructions and screenshots to guide you through the creation of a complete, cost-effective telephony system. You will start with installation, walk through the different features, and see how to manage and maintain the system.
Who this book is written for
If you are an IT professional or enthusiast who is interested in quickly getting a powerful telephony system up and running using the free and open source application FreeSWITCH, this book is for you. Telephony experience will be helpful, but is not required.
Now, here are my impressions. Please bear in mind that I did not actually attempt to build a working FreeSWITCH installation (I would need yet another spare computer to do that), but I certainly feel as though I could after reading this book. One thing that is somewhat uncommon about this book is that the author of the software is also one of the authors of the book. Too often, when you see a book written about a piece of software, the writer doesn’t fully understand the software and therefore makes guesses and assumptions about how it works, that may lead to problems down the road if you follow their advice. When the software author collaborates on the book, that’s far less likely to happen, and indeed, at no point in this book did I get the feeling that the author was struggling to understand the subject. I will even go so far as to say that this is one of the best written technical books I have read in a long time.
The biggest complaint I had about this book — and it is a very minor one — is that it could have benefited from another proofreader. Occasionally I’d see an obvious error that the proofreader should have caught — nothing major, and nothing I couldn’t figure out with about two seconds of thought, with one exception. On page 91 of the book, it appears to me as though there is some missing text at the bottom of the page. It’s discussing making a test call to Music on Hold and then, suddenly and jarringly, it jumps into a time of day example. I think the disconnect occurs in middle of a sentence: “In our example, call the debug output is as follows:” The sentence as written does not make sense to me, and it appears a block of text (perhaps a large one) may have been omitted at this point. But that is the only place in the book where I encountered an error of that magnitude. I have submitted the error to Packt Publishing and I’m hoping they will figure out what was supposed to go there and place it in the errata section of their web site.
One other point I will make about a software author writing a book on his own creation is that I think sometimes, it’s difficult for the author to correctly envision how end users will want to use the software. As an example, virtually all the dialplan examples in this book are in XML. There may be advantages to using XML, but it’s not going to be very familiar to someone coming from an Asterisk background, and I might have wished for a few non-XML examples. On pages 158-159, the author notes that,
There is a common misconception that the FreeSWITCH Dialplan is based on, and requires, XML. That is simply not true. If you prefer flat files, you could use them to store your Dialplan configuration. If you prefer YAML, you could use that, too. You just need to load the correct C-based Dialplan module to interpret your stored logic for the particular type of configuration file you want FreeSWITCH to utilize.
This aside, the most common (and currently, the most robust) Dialplan processing mechanism in FreeSWITCH is still the XML-based Dialplan module. Most Dialplan examples that are shipped with FreeSWITCH, or those scattered on the Web are in XML, therefore, they will remain the focus of this chapter. …..
Indeed, there is even an Asterisk dialplan module, albeit with limited capabilities. From page 199:
If you are used to the Asterisk Dialplan, some basic functionality is provided by the Asterisk Dialplan module, although it is not nearly as feature-rich as the XML engine. You can process contexts and route calls to phones using the Asterisk Dialplan. This module, again, is more of a sample on how to build an alternate Dialplan processing module and should not be utilized as a full, feature-rich Dialplan system.
Yet you won’t find examples using flat files, YAML, or Asterisk Dialplan in the book. However, the XML examples were clearly written and easy to understand, so I don’t think that there would be a steep learning curve to start writing dialplans in XML, assuming you are a proficient enough coder to write dialplans in the first place. And, I suspect that XML would be easier for a new user to pick up than any of the other options.
I mention the above to emphasize two points: FreeSWITCH is different from Asterisk. If you are thinking about moving from Asterisk to FreeSWITCH, you need this book to get you up to speed on the differences. And second, FreeSWITCH is both more capable than Asterisk, and arguably easier to use, once you get used to the differences (or if you have no prior experience with similar software). FreeSWITCH appears to have been designed from the ground up to avoid the issues that have plagued Asterisk, particularly those that cause Asterisk to fall to its knees under heavy load or heavy call volumes. Even if you’re a long-time Asterisk user, you may want to get this book just to see what you’re missing. You might decide that it’s worth your effort to set up a test system using FreeSWITCH, to help you understand how much better the next generation of telephony software engines can be.
One other point, in case you are reading this review several months after I wrote it — the author notes this in the preface:
At the time of this writing this book, the FreeSWITCH developers were putting the finishing touches on FreeSWITCH version 1.2. While the examples presented in this book were specifically tested with version 1.0.6, they have also been confirmed to work with the latest FreeSWITCH development versions that form the basis of version 1.2. Do not be concerned about the fact that this material does not cover version 1.2—it certainly does. The FreeSWITCH user interface is very stable between versions; therefore, this text will be applicable for years to come.
There will no doubt be some of you who are reading this that wonder if there are any Web GUI “front ends” (dialplan and configuration file generators) for FreeSWITCH. Indeed there are, and they are covered in Chapter 10, which briefly explains the differences between WikiPBX, FreePBX v3, FusionPBX, and 2600hz. Even if you plan on using a Web GUI, there may be times when you find the need to write a bit of custom code, and in that case having this book available would definitely be helpful to you.
One other thing I personally found interesting in this book was Appendix B, “The History Of FreeSWITCH.” This explains how FreeSWITCH came to be, and along the way offers further explanation on how it is different from Asterisk and why the developers felt the need to start a new project. What I think I found most interesting (and perhaps unfortunate, depending on your point of view) is that FreeSWITCH could have been the basis for Asterisk version 2, had only the Asterisk developers reacted positively to the idea. I see this sort of thing happen occasionally in the open source community, where the lead developers of a project start to develop an attitude that does not encourage outside contributions (or, they treat contributions or suggestions for improvement as if they were piles of steaming dog poo on their doorstep). Perhaps this should serve as a cautionary tale to such developers that your project can always be replaced by something better, if you do not encourage contributions to your own project from those not currently in your “inner circle” of developers.
As you may know if you have read my previous reviews, it’s rare that I get wildly enthusiastic about a book. In this case I’ll make an exception, because overall the book is that well-written (my comments above notwithstanding). If you have any interest at all in using FreeSWITCH, or are even just curious about it, you really should buy this book. It’s available in both traditional softcover dead-tree format, and as a DRM free Adobe PDF eBook, and there’s even a package deal if you want both formats. Don’t forget that you can view a sample chapter (PDF format) prior to purchase. EDIT: Also, there is an online article by the book’s authors entitled FreeSWITCH: Utilizing the Built-in IVR Engine.
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.
Notice
EDIT March, 2014 and August 2020: If you are running OS X Mavericks or later, or any version of MacOS we recommend that you do NOT use the script shown here, but instead send notifications to a XMPP/Jabber account and use either Apple’s Messages app (formerly iChat) or a third party messaging program such as Adium to receive them, since the message will then display in the Notifications Center and you do not need Growl. See How to send various types of notifications on an incoming call in FreePBX for more information. You may also find this thread on the RasPBX forum useful.
What follows will probably not work on ANY currently supported version of MacOS and is left here as a historical reference only.
Quite some time ago, I wrote a post explaining how you could poll a Linksys or Sipura VoIP adapter or phone once per second, and whenever there was an incoming call, generate a notification popup on your computer, if you have the Growl notification service installed. However, that method doesn’t work if you’re not using a Linksys or Sipura phone or device.
If you are running Asterisk, there’s another way to do it, and that’s to get Asterisk to send the notifications directly. In order for this to work, the computer on which you want to receive the notifications has to be running Growl (under Mac OS X) or Growl for Windows. You must also configure Growl to receive network notifications. I will note here that if you are using a Mac and have never done that before, you may want to make sure that Growl network notifications work before proceeding, because it appears that under OS X, it’s pretty much a crap shoot whether Growl network notifications will work at all, and when they don’t the Growl folks apparently have no clue as to why they don’t. It seems to be a machine-specific thing – on some Macs they work fine, while on others they don’t work at all.
You must have the Perl language installed on your Asterisk server, and you must have the Net::Growl and Asterisk::AGI modules installed (I’m going to assume you know how to install a Perl module from the CPAN repository – if you have Webmin installed, it can be done from within Webmin). Chances are you already have Asterisk::AGI installed, unless you built your Asterisk server “from scratch” and never installed it, but if you’ve never installed Net::Growl you’ll need to do that first.
Next you want to copy and paste the following Perl script to the filename /var/lib/asterisk/agi-bin/growlsend.agi on your Asterisk server (to create a non-existent file, you can use the touch command, and after that you can edit it in Midnight Commander or by using the text editor of your choice). If this code looks somewhat familiar, it’s because it’s adapted from some code that originally appeared in a FreePBX How-To, which I modified.
#!/usr/bin/perl
use strict;
use warnings;
use Net::Growl;
use Asterisk::AGI;
my $agi = new Asterisk::AGI;
my %input = $agi->ReadParse();
my $num = $input{'callerid'};
my $name = $input{'calleridname'};
my $ext = $input{'extension'};
my $ip = $ARGV[0];
if ( $ip =~ /^([0-9a-f]{2}(:|$)){6}$/i ) {
$ip = $agi->database_get('growlsend',uc($ip));
}
unless ( $ip =~ /^(d+).(d+).(d+).(d+)$/ ) {
exit;
}
open STDOUT, '>/dev/null';
fork and exit;
if ( $ARGV[2] ne "" ) {
$ext = $ARGV[2];
}
# Define months and weekdays in English
my @months = (
"January", "February", "March", "April", "May", "June",
"July", "August", "September", "October", "November", "December"
);
my @weekdays = (
"Sunday", "Monday", "Tuesday", "Wednesday",
"Thursday", "Friday", "Saturday"
);
# Construct date/time string
my (
$sec, $min, $hour, $mday, $mon,
$year, $wday, $yday, $isdst
) = localtime(time);
my $ampm = "AM";
if ( $hour > 12 ) {
$ampm = "PM";
$hour = ( $hour - 12 );
}
elsif ( $hour eq 12 ) { $ampm = "PM"; }
elsif ( $hour eq 0 ) { $hour = "12"; }
if ( $min < 10 ) { $min = "0" . $min; }
$year += 1900;
my $fulldate =
"$hour:$min $ampm on $weekdays[$wday], $months[$mon] $mday, $year";
# Next two lines normalize NANP numbers, probably not wanted outside of U.S.A./Canada/other NANP places
$num =~ s/^([2-9])(d{2})([2-9])(d{2})(d{4})$/$1$2-$3$4-$5/;
$num =~ s/^(1)([2-9])(d{2})([2-9])(d{2})(d{4})$/$1-$2$3-$4$5-$6/;
register(host => "$ip",
application=>"Incoming Call",
password=>"$ARGV[1]", );
notify(host => "$ip",
application=>"Incoming Call",
title=>"$name",
description=>"$numnfor $extn$fulldate",
priority=>1,
sticky=>'True',
password=>"$ARGV[1]",
);
Also, if you want to be able to specify computers that you wish to send notifications to using MAC addresses rather than IP addresses (in case computers on your network get their addresses via DHCP, and therefore the IP address of the target computer can change from time to time), then you must in addition install the following Perl script. It requires a command-line utility caller arp-scan so install that if you need to – I used to use nmap for this but they changed the output format, making it harder to parse, and arp-scan is much faster anyway. Call it /var/lib/asterisk/agi-bin/gshelper.agi and note that there are two references to 192.168.0… within it that you may need to change to reflect the scope of your local network, if your network’s IP addresses don’t start with 192.168.0.:
#!/usr/bin/perl
use strict;
use warnings;
my @mac;
# Change the following lines to reflect the scope of your local network, if necessary
my @arp = `arp-scan --quiet --interface=eth0 192.168.0.0/24`;
foreach (@arp) {
if (index($_, "192.168.0.") == 0) {
@mac = split(" ");
`/usr/sbin/asterisk -rx "database put growlsend \U$mac[1] $mac[0]"`;
}
}
Make sure to modify the permissions on both scripts to make them the same as other scripts in that directory (owner and group should be asterisk, and the file should be executable), and also, if you use the gshelper script, make sure to set up a cron job to run it every so often (I would suggest once per hour, but it’s up to you).
Now go to this page and search for the paragraph starting with, “After you have created that file, check the ownership and permissions” (it’s right under a code block, just a bit more than halfway down the page) and if you are using FreePBX follow the instructions from there on out (if you are not using FreePBX then just read that section of the page so you understand how this works, and in any case ignore the top half of the page, it’s talking about a different notification system entirely). But note that if you use the above code and have the gshelper.agi program running as a cron job, then after the first time it has run while the computer to receive the notifications is online you should be able to use a computer’s MAC address instead of the IP address. This only works if you’ve used the modified script on this page, not the one shown in the FreePBX How-To. As an example, instead of
(the above is all one line) where 01:23:45:AB:CD:EF is the MAC address of the computer you want to send the notification to. Once again, just in case you missed it the first time I said it, this won’t work until the gshelper.agi script has been run at least once while the computer to receive the notifications was online. If for some reason it still doesn’t appear to work, run the nmap command including everything between the two backticks (`) directly from a Linux command prompt and see if it’s finding the computer (depending on the size of your network, it might be several seconds before you see any output, which is why I don’t try to run this in real time while a call is coming in).
If you are NOT running FreePBX, but instead writing your Asterisk dial plans by hand, then you will have to insert a line similar to one of the above examples into your dial plan, except that you don’t need the four asterisks (****) in front of the extension number, and if it’s not the first line in the context, you’ll probably want to use n rather than 1 for the line designator (and, you won’t be putting the line into extensions_custom.conf because you probably don’t have such a file; instead you’ll just put it right in the appropriate section of your dial plan). In other words, something like this (using extension 525 as an example):
This line should go before the line that actually connects the call through to extension 525. I do not write Asterisk dial plans by hand, so that’s about all the help I can give you. And if you don’t write your dial plans by hand, but you aren’t using FreePBX, then I’m afraid you’ll have to ask for help in whatever forum you use for advice on the particular software that you do use to generate dial plans, because I can’t tell you how to insert the above line (or something like it) into your dial plan.
Virtually everything in this article has already been published in one place or another, but I wanted to get it into an article with a relevant title and cut out some of the extraneous explanations and such. There are links to all the original sources throughout the article, so feel free to follow those if you want more in-depth commentary.
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 ###
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:
But 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.
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.
This article was originally posted in June, 2010.
I recently had the experience of trying to help someone make a Sangoma USBfxo device (model U100) work on a server that runs FreePBX and Asterisk. The advertised features of this device are as follows:
Dual FXO ports
Easy installation, no need to open up computer to install PCI/PCIe card
Supports up to 2 simultaneous calls
Compact plastic enclosure
Low power consumption, takes power from USB bus
USB 2.0 compliant (compatible with USB 1.1)
The first thing I would note is that although you don’t have to open up the computer, it’s definitely not “plug and play.” At the very least you have to install driver software, and on an Asterisk server you will also need to install and configure DADHI or ZAPTEL (unless this has already been done). Depending on your level of expertise, this might be easy, or quite daunting. I would certainly take issue with the claim of “easy installation” although I can understand how a true Linux geek might consider it a walk in the park. It wasn’t so much that there were any major hitches in the installation as that it was time consuming and required quite a bit of mental effort to figure out what needed to be done — someone who has just set up a PBX using a “load and go” distribution like Elastix, PBX in a Flash, AsteriskNOW, Trixbox, etc. might not find it all that easy to get this thing working.
The major issue we had was with the performance. We initially discovered that it was “clipping” speech severely, causing audio artifacts that are difficult to describe in print, but unpleasant to hear. We got in touch with Sangoma customer support and finally traced the problem to the built in hardware echo cancellation. By disabling the hardware echo cancellation, the speech was clear, but of course we then had mild echo. Enabling echo cancellation in Zaptel fixed that on a temporary basis, but about a week later Sangoma customer support e-mailed us and suggested that we try OSLEC, the open source echo canceler. We might have actually done that had we not discovered another issue in the meantime, that made us decide we didn’t want to mess with this unit anymore.
This new issue was that initially, it did not pick up incoming caller ID on incoming calls. We discovered that this could be fixed by changing the gain settings in Zaptel, but even when we did that it still wasn’t 100% reliable (I’d say it worked about 90% of the time). And, the downside of that was that we had to reduce the incoming gain, so that it was harder to hear callers.
We’ve used Sipura SPA-3000’s before for this same function, although they are only single line units (they have one FXS port and one FXO port) and have never had any of these issues. The main reason we tried the USBfxo was because we wanted two FXO ports, and also liked the idea that it was powered off the USB cable, and didn’t require us to have yet another device with a “wall wart” to plug in. But the difficulties with Caller ID, volume levels, and the fact that Sangoma had apparently given up on getting the hardware echo cancellation to work without distorting the audio led us to get frustrated with this device fairly quickly. The non-techies that had to make and receive calls that went through this device were not very understanding of the issues, especially since the SPA-3000’s (now superseded by the Linksys SPA-3102, which is essentially an updated version of the Sipura SPA-3000) had always worked much more reliably. We finally gave in and found another Sipura SPA-3000 on eBay and put it into service, and within a relatively short time (part of which was spent locating and installing updated firmware) it was working like a champ. Unlike the Sangoma, it detects the Caller ID 100% of the time, and we can tweak the transmit and receive gain to comfortable levels.
My personal opinion is that Sangoma should be ashamed to put their name on the USBfxo. The hardware echo cancellation, in a word, sucks. And one of the big reasons you’d buy a brand like Sangoma in the first place is because of the supposedly superior echo cancellation. Echo cancellation is supposed to cancel echo, not make it sound like your words are clipped. My guess is that the hardware echo cancellation is far too aggressive and they don’t give you any way to “tune” it — you can either enable or disable it, but that’s all. The USBfxo is a great idea, but it needs to go back to the drawing board. Sangoma’s motto (shown on their Wiki pages, etc.) is “Because it must work!”, but apparently that motto does not imply that it must work well!
Also, a note to Sangoma customer service — next time a customer is dropping hints that they’d like you to take your defective unit back and send a replacement, you might want to be a bit more responsive to that request. We were willing to work with you up to a point but the message came through loud and clear that you really didn’t want to replace this dog of a device unless you absolutely had to. We didn’t sign up to be beta testers, we just wanted the damn thing to work. Given Sangoma’s (perhaps undeserved) reputation we really thought you’d be more agreeable to making sure that we got a unit that worked, not making us try a bunch of different things and then ultimately told to try OSLEC, effectively giving up hope that the hardware echo cancellation would ever work properly.
Another suggestion to Sangoma (or any other manufacturer that may be listening) — most of us who did not cut our teeth on Linux would probably prefer not to have to mess with ZAPTEL or DADHI. The nice thing about the Linksys/Sipura devices is that they sit out on the network and appear as just another SIP-based device, and in FreePBX you configure them pretty much as you would any other SIP trunk. I’m not saying that installing any of these devices is the proverbial “piece of cake”, especially if you have never done it before, but when you have to start installing and configuring drivers, that goes outside of the realm of what I would consider easy to install. What someone really needs to come out with is an inexpensive four to six-port SIP based FXO device that sits out on your local network, like the SPA-3000/3102.
If you are in need of one or two FXO ports for your Asterisk server, my advice would be to first try one or two Sipura SPA-3000 or Linksys SPA-3102 devices (following these instructions if you are a FreePBX user) — if those do not work the way you’d like, you can always resell them on eBay and then try a more expensive solution. If your server doesn’t have card slots (as is increasingly the case, as users turn to small computers like the Acer Aspire Revo to use as small, power-efficient PBX’s) then your choices are limited to external devices such as the aformentioned units. However, if your system can accept internal cards, then you can buy cards that provide FXO ports from several manufacturers, including Digium and Sangoma (if you need eight or more FXO ports than I believe there are other external options, but they are quite a bit more pricey and I have not really investigated them, so I won’t comment on them at this point. However, if any manufacturer would care to send a review sample, I’d be more than happy to give it a try!). 😉
The one caveat I will add is that not every device will work on every line. If you have a very long line from a traditional telephone company, your requirements (and experience with a particular device) may be quite different from someone who is sitting 500 feet from the central office, or someone who’s trying to take the output of a cable company’s VoIP adapter and pipe it over to the FXO card or device using twenty feet of copper wire. Just because the Sipura devices have worked better for us does not mean they will for you. I’m guessing that some people have purchased the exact same Sangoma device that we tried and were able to get it working well enough for their needs, but I just cannot recommend this device — at least not until Sangoma fixes the echo cancellation, and makes it read the incoming Caller ID reliably 100% of the time, preferably without having to change the incoming gain in DADHI or ZAPTEL.
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which in turn was reposted with the permission of the original author from a now-defunct Macintosh-oriented blog. It is reposted with his permission. Comments dated before the year 2013 were originally posted to The Michigan Telephone Blog.
If you bought a Sharp LC-42SB45U TV, perhaps because it was on a super great (and very lightly advertised) deal at Wal-Mart back in November, and then later tried to hook up a home theater PC to it, you may have been disappointed to discover that unlike most flat screen digital TV’s it doesn’t have a “pixel-to-pixel” or similar 1:1 pixel mapping mode. The result is that when you hook up a computer to one of the HDMI ports, there is a serious overscan problem — for example, if you are running Ubuntu Linux (or some other version of Linux) you won’t see the top or bottom menu bars, because they are outside the visible screen area. If you use XBMC or Boxee, you can go into that program’s settings menu and apply overscan correction from within the program, but most other programs and video players don’t offer an overscan correction option.
The problem is not that there’s no “Dot by Dot” setting in the Sharp TV — it’s just that it’s a (very) hidden option, and as far as I know, there is nothing you can do using the buttons on the TV or on the remote to make it appear (I’d be very happy to be proven wrong on this point; if there is some sort of hidden remote control key sequence that can make the Dot by Dot option always appear, I wish someone would spill the beans so we can fix this issue the right way). But with one small tweak in a Linux configuration file, you can make it appear, like so:
Sharp LC-42SB45U TV showing Dot by Dot option
My first approach to this came at a cost: I read that if you could send the Sharp a non-standard vertical sync frequency (refresh rate) a bit below the normal 60 Hz, the alternate View Mode would appear. That did work, and in my non-scientific testing, I found that 59.55 Hz was about the cutoff point. Anything above that, and you get the normal menu of View Mode options when you press the View Mode button on the remote. Anything at about that or below, and you get the View Mode options menu shown above. However, this was certainly less than ideal because of the non-standard refresh rate. I got started on that path after reading a forum post that suggested a custom ModeLine in your /etc/X11/xorg.conf file to give you a 1816×1026 display. While this will work to fix the overscan, it also cuts down on the pixels available to programs, and makes things not quite as sharp (no pun intended) as they should be.
Now, the idea of using a custom ModeLine in your /etc/X11/xorg.conf file is not a bad idea, and the above-referenced post did contain some good information (especially about disabling some unwanted Ubuntu packages that might cause your xorg.conf to be ignored). So I tried the xorg.conf shown in that post, except I used the original ModeLine shown (which is correct for the Sharp LC-42SB45U as long as you don’t mind the overscan). I then read in another forum post (on a different site) that someone had found that the Dot by Dot option would appear if the refresh rate were set to 59 Hz rather than 60 Hz. However they were doing that on a Windows machine, not a Linux box, if I recall correctly.
But again, that had the disadvantage of a non-standard refresh rate. I’ve read on several sites that the ideal refresh rate is 59.94 Hz (it’s very close to 60 Hz and is exactly twice the ATSC 1920×1080 progressive scan frequency of 29.97 Hz) so my goal was to get as close to that as possible. I then read that someone had actually accomplished this on a Windows box by changing the timing to something called “CVT reduced blank” (the procedure on a Windows box is to bring up the NVIDIA Control Panel, then click on Change Resolution, then Add Resolution, then Create Custom Resolution, then in the “Timing” section find the “Standard” drop-down box and select CVT reduced blank. Make sure the other settings look sane, click the Test button and go from there. Mac OS X users can do something similar using a program called SwitchResX — see Brian Semiglia’s comment in the Comments section for a link to instructions. The reason this doesn’t work under Linux is that the Linux version of the NVIDIA Control Panel doesn’t offer this level of functionality, and also, some might encounter this issue even if not using NVIDIA graphics). So my goal was to find a ModeLine that would do the CVT reduced blank but not use a non-standard screen size nor refresh rate. After searching the web, playing around with an online Calculator for video timings which I saved to a local drive and then hacked a bit to display four decimal points of precision on some key values, and generally spending more time than I intended, I came up with a working ModeLine.
First, let’s look at the original 1920×1080 ModeLine from the above-linked forum post:
If you change the pixel clock frequency value in a ModeLine (the 148.50 in the line shown above) you change the refresh rate, and if you change certain other values you change the other timings. I cheated a bit and used Google to search for a working ModeLine that provided 1920×1080 at 59.94 progressive scan, and found one that was very close (59.93, actually) so I tweaked the refresh to give me exactly 59.94. This is the final ModeLine I came up with:
Okay, so you may think it ridiculous to specify the pixel clock frequency out to four decimal places, but hey, it works! So, this is what I’m now using for an xorg.conf file (by the way, if any of the ModeLines in this article are truncated on your display, just keep in mind that the last two values in each line are +hsync +vsync — if you copy and paste any of the long ModeLines, hopefully you’ll get the complete line). Bear in mind that I’m using this with an Acer Aspire Revo, so some of these lines are specific to the NVIDIA graphics chipset, but the principle of changing the ModeLine probably should work with this model Sharp TV even if some other graphics chipset is used on the computer:
This seems to work well on a Acer Aspire Revo running Ubuntu Karmic Koala (EDIT: and I’ve also used it under Maverick Meerkat), though I imagine it would work with other Linux distributions that use an xorg.conf file (including XBMC Live), however as far as I know this trick only works with the Sharp LC-42SB45U TV and no other model. With this xorg.conf I don’t have to tweak the overscan settings in XBMC or Boxee at all. It works for me, but it may or may not work for you. Standard disclaimers apply – I’m not telling you to do this on your setup, and if you break something, you own all the pieces, but from me you’ll get nothing more than perhaps a bit of sympathy. Don’t even think of doing this if you are not willing to assume any and all risks.
EDIT: If you don’t want to go through all the hassle I went through to calculate the correct ModeLine, you can run the cvt program with the -r option from the Linux command prompt, like this:
cvt -r 1920 1080
That’s for a 1920 x 1080 display. On my system this generated the following output:
You’ll notice this is nearly identical to the ModeLine I generated (the vsync is the opposite, though — don’t know if that would be an issue). What I’ve read is that you paste the generated ModeLine into your xorg.conf file and make sure you also have the line
Option "ExactModeTimingsDVI" "TRUE"
in your xorg.conf (to force it to use your generated ModeLine) and that may be all you need. Certainly simpler than how I did it, but I didn’t know about the cvt program. (End EDIT).
By the way, if you want to hack that Calculator for video timings, just save the HTML page to your local hard drive, open it in a text editor and look for this section (it’s very close to the top):
function TwoDecimal(number) {
number=((Math.round(number*100)/100));
return number;
}
Change that second line to
number=((Math.round(number*10000)/10000));
Then load the page into your favorite browser (with JavaScript enabled). That will display a couple extra decimal points on some of the critical values.
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.
Here’s what the publisher wants you to know about the book (my comments will follow):
In Detail
OpenVPN is a powerful, open source SSL VPN application. It can secure site-to-site connections, WiFi, and enterprise-scale remote connections. While being a full-featured VPN solution, OpenVPN is easy to use and does not suffer from the complexity that characterizes other IPsec VPN implementations. It uses the secure and stable TLS/SSL mechanisms for authentication and encryption. This book is an easy introduction to this popular VPN application. After introducing the basics of security and VPN, it moves on to cover using OpenVPN, from installing it on various platforms, through configuring basic tunnels, to more advanced features, such as using the application with firewalls, routers, proxy servers, and OpenVPN scripting.
This is a practical guide to using OpenVPN for building both basic and complex Virtual Private Networks. It will save you a lot of time and help you build better VPNs that suit your requirements. While providing only necessary theoretical background, the book takes a practical approach, presenting plenty of examples. It starts with an introduction into the theory of VPNs and OpenVPN, followed by a simple installation example on almost every available platform. After a concise and ordered list of OpenVPN’s parameters, we dive into connecting several machines in a safe way. The last third of the book deals with professional and high-end scenarios, and also mobile integration. After having read the whole book and followed and understood all the examples, you will be an expert in VPN, Security, and especially in OpenVPN Technology. This book was written for version 2.0.9 of OpenVPN, but all examples have been tested and run smoothly on version 2.1 too. Read the full Table of Contents for Beginning OpenVPN 2.0.9
What you will learn from this book
Install OpenVPN on Windows Server, Vista, and Mac OS X and also on different Linux versions and FreeBSD
Learn basic security concepts necessary to understand VPNs and OpenVPN in particular
Take a look at encryption matters, symmetric and asymmetric keying, and certificates
Connect Windows and Linux systems and safely transfer the necessary encryption keys using WinSCP
Learn about OpenVPN, its development, features, resources, advantages, and disadvantages compared to other VPN solutions, especially IPsec
Discuss non-standard and advanced methods of installing OpenVPN by compiling the source code provided by the OpenVPN project
Create an encryption key for OpenVPN and use it to set up an OpenVPN tunnel between two Windows systems in the same network
Create X.509 server and client certificates for use with OpenVPN and learn how to use tools to debug and monitor VPN tunnels
Create and administer certificates that have to be transferred to the machines that are supposed to take part in the VPN
Configure two different firewall networks that connect to each other through the secure OpenVPN tunnel
Install and use XCA and TinyCA2 to generate certificate revocation lists that are used to block unwanted connections by formerly authorized clients
Install OpenVPN on Windows Mobile and Smartphones running embedded Linux, like Nokia’s Maemo platform
Analyze the flow of datagrams between the VPN servers and the connected networks with tools like ifconfig, ping, traceroute, and mtr
Approach
This book is an easy introduction to OpenVPN. While providing only necessary theoretical background, it takes a practical approach, presenting plenty of examples. It is written in a friendly style making this complex topic easy and a joy to read. It first covers basic VPN concepts, then moves to introduce basic OpenVPN configurations, before covering advanced uses of OpenVPN.
Who this book is written for
This book is for both experienced and new OpenVPN users. If you are interested in security and privacy in the internet, or want to have your notebook or mobile phone connected safely to the internet, the server in your company, or at home, you will find this book useful. It presumes basic knowledge of Linux, but no knowledge of VPNs is required.
Now back to my mini-review. If you read my original review (which explains why I think a VPN can be an important part of securing private VoIP networks, among other uses), you know that I found Mr. Feilner’s original book quite helpful in giving me a grasp on VPNs, a subject I’d known very little about prior to that point. There were a few things I thought could have been covered better, though, so I was interested to see if those things had been addressed in this updated edition.
As I had more or less noted, the author seemed to slightly prefer SuSE Linux over other versions of Linux, and the Shorewall firewall over other Linux firewall solutions, and (in my opinion) the new book still uses more pages than are really necessary talking about how to set up and configure Shorewall, but at least now the authors do provide some minimal information about the far more popular iptables firewall tool (a little over three pages). It would have been nice to see a more in-depth treatment of this subject, because sometimes setting up iptables correctly is one key to getting your VPN to work as you want it to, particularly if you need or want to do anything more complicated than a simple VPN tunnel. It’s a minor nit, to be sure, because there’s plenty of information on the web about how to set up and configure iptables, but I personally would have given that topic more than three pages.
Then I discovered they’d made one addition that I really wanted to see: A totally new chapter on OpenVPN GUI tools, and in particular, a section on Webmin’s OpenVPN plugin. My disappointment again was that this was not a more exhaustive treatment of the subject. Actually, it’s little more than a mention that the plugin exists, and a few screenshots. Granted that this was more than appeared in the original volume, and just informing readers of the existence of that plugin is no small thing, but when I did my series on Setting up an OpenVPN tunnel using a CentOS-based system as the server and a router flashed with Tomato firmware as the client, it took me twoparts to explain how to configure the Webmin plugin. That same chapter also talks about some client GUI’s for Linux, but doesn’t spend more than a page or two on any of them.
I’m not really faulting the authors here — it’s very apparent that they write about what they know, and they definitely know their stuff when it comes to OpenVPN, whereas they may not be quite as familiar with Webmin or iptables. That said, Windows users should find all the information they need to set up an OpenVPN tunnel and then some, and Linux newbies get enough information to at least point them in the right direction. As for Mac users, the coverage there is about the same as in the previous edition, which is to say that there’s about three pages on how to install Tunnelblick. However, much of the information in the book is not OS specific, and those with some experience with Linux or OS X should have no trouble at all following along.
On a positive note, there are many examples and screenshots in the book, and in this one the screenshots are actually readable (well, I did need my reading glasses for a few of them, but then I’m getting to the point where I need my reading glasses to read the cooking directions on a frozen dinner!). And, the authors’ writing style is clear and easy to understand. Also, there’s a totally new (albeit relatively short) chapter on Mobile Security, which may be of interest to some of the “road warriors” out there.
So, my recommendation is this: If you read Markus Feilner’s previous book on OpenVPN and liked it, you’re almost certainly going to want to read this one, just to get up to date. If you didn’t read the previous edition but just want to get up to speed on OpenVPN, this really is one of the better books on the subject, provided that you understand that at times you may have to supplement the book with a bit of additional research on the Web, particularly if you are running OS X or Linux as your operating system (but at least you’ll have a much better handle on topics for additional research).
The reason this is a mini-review and not a full review is because due to personal/family issues I haven’t had time to do much more than skim through the new book, rather than give it a complete read as I normally prefer to do. But since Packt Publishing kindly sent me the book over a month ago, I feel as though it’s a disservice to both them and to the readers of this blog to delay mentioning it any longer. Despite my comments about the paucity of additional pages on the particular topics I’d hoped to read more about, this is still a great book for those who need to set up and secure an OpenVPN tunnel, particularly if you’re just starting out and know next to nothing about VPNs and/or OpenVPN.
This is a heavily 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.
This article was originally published in January, 2010. Things have changed considerably since then, and most of what was shown in the original article is no longer necessary. You install Ubuntu, then you install XBMC, and it pretty much just works. And if you want an even better experience, you might want to look into installing XBMCbuntu. There may be a few hints in this article that are still applicable but you are very likely going to find that most things just work. One thing you may (or may not) need to do is completely uninstall and then reinstall lirc, because it may not show you the window that lets you select your remote (assuming you have purchased an infrared remote that has a receiver that connects to the USB port), and on the re-install of LIRC you should see the selection window and be able to pick your correct remote. Or, better yet, you can skip the removal/reinstall by running dpkg-reconfigure lirc from a terminal prompt (which will bring up the remote control selection window).
Another thing that you might want to do is consider using Linux Mint rather than Ubuntu, particularly if you hate the new Unity interface.
The original genesis of this installation was an article at the Lifehacker site entitled Build a Silent, Standalone XBMC Media Center On the Cheap. While that article is probably outdated, you may still want to read it first, then come back here.
The first thing you need to know is that there are several different models of the Acer Aspire Revo out there. You want the highest powered model you can get, and in particular, the most memory and highest number of processors. Even the high-end ones are very reasonably priced if you shop around, and even moreso if you can score a good, gently-used unit. Note that you CAN buy an Acer Aspire Revo with some version of Windows installed, but it will cost you more and (especially in the higher end models) and for a standalone media center, Linux works better anyway, so why pay extra for an operating system you may never use?
You’ll need a wireless or USB keyboard and mouse during the setup phase. Some Revo sellers include a wireless keyboard and mouse, while others don’t, so just be aware of that when ordering. Read specifications VERY carefully and know what you are buying! Also consider, if you get a defective keyboard (we did), will it cost more to ship it back than what you’d spend to buy a replacement locally (probably yes, if you buy from an overseas seller)? Don’t overlook pre-owned Revo’s — as long as they are still in good working condition and have a model number in the 3000 series or above, they should be fine (the main thing to make sure of is that they have the maximum amount of memory). Be aware that some early models did not have a digital audio output, so if that’s important to you (and it probably is in this application), be careful what you buy.
Also, the Lifehacker article wants you to install the operating system from a thumb drive. If you have an external CD or DVD drive (that connects using a USB port) do yourself a favor and use that (just install from the distribution CD). By the way, speaking of USB ports, at least some Revo models have a sixth (hidden) USB port. It’s right next to the power switch, on the narrowest part of the case — if you see a small, rubbery insert with a USB logo on it, you can peel that off with your fingernail to reveal the hidden USB port (not that you’d want to unless you really need the sixth port).
Probably the most important thing in that Lifehacker article is the BIOS tweaks. Note that most newer Revos don’t seem to have the “Boot to RevoBoot” option, so if you can’t find that setting, don’t worry about it. Also, if you get a newer, higher end unit with more memory, set the iGPU Frame Buffer Size to 512MB, not the 256MB that the article suggested for the low-end unit that Lifehacker used for their build.
Installing Ubuntu is easy; you basically answer the few questions asked during the installation, and stay with the defaults when you are not sure how to answer. You probably do want it to take over the entire hard drive, so make sure you have saved anything you might want from that drive before you begin the install. We strongly recommend using a 32 bit version of Ubuntu – even though the Revo technically supports a 64 bit operating system, we have found that many things simply don’t work right with the 64 bit OS. If you insist on trying the 64 bit version, you’l probably at the very least need to work through several issues.
If you’re totally inexperienced with Linux, you probably should grab the latest full install disk image of Ubuntu and burn it to a CD, or if you really want to try installing it from a USB memory stick, a visit to the Pen Drive Linux site may help you get the image onto the USB stick in the first place. We used the Ubuntu Minimal CD Image for the install, to save time downloading a huge CD image that is mostly replaced during the software update process. If you go that route, be sure to read the instructions on that page carefully, or you’ll be scratching your head wondering why it’s not working! When you type “tasksel” to select the system to install as instructed, you’ll want to install the standard Ubuntu Desktop but there may be other options you’ll want to install as well, such as an ssh server and/or samba server (those might already be present in the Ubuntu desktop install, but it won’t install anything twice, so I just checked those to be on the safe side).
If you do as most users probably will, and download an ISO file, burn it to a CD, and install from that (using an external CD or DVD drive), just be sure that you check any boxes to install additional codecs or to use additional repositories, if offered any such options.
After installing the operating system, if the nVidia drivers were not installed (very unlikely unless for some reason your video hardware wasn’t detected properly), the next task is to install them. The system should offer to do this automatically (look for an icon in the top panel).
You can install Software using the Ubuntu Software Center, but not all available software is available there. You can also install Synaptic if you wish, from the Ubuntu Software Center or using apt-get install synaptic from a terminal window. When I mention installing software, I suggest you try the Ubuntu Software Center first, and if you don’t find it there, then try Synaptic or apt-get.
You might want to start by installing mc (Midnight Commander) – I wouldn’t have a Linux box without it, but that’s just me.
In newer versions of Ubuntu you may also want to consider installing ClassicMenu Indicator, which is a notification area applet (application indicator) for the top panel of Ubuntu’s Unity desktop environment. It provides a simple way to get a classic GNOME-style application menu for those who prefer this over the Unity dash menu. Like the classic GNOME menu, it includes Wine games and applications if you have those installed. It looks like this:
ClassicMenu Indicator
If you want to be able to access your HTPC from other computers on your local network using SSH, install openssh (you don’t need to do this if you installed an ssh server using the minimal install, or if you find that ssh already works) and (optionally) sshguard. Then edit /etc/ssh/sshd_config and change the PermitRootLogin value from “yes” to “no” (for the sake of system security).
Another thing you want to do is make sure that the system time be kept synchronized with Internet servers. Right click on the clock applet in the top panel, then select Time & Date Settings, and make sure everything looks right there (especially that the option to set the time “Automatically from the Internet” is selected).
Now it’s time to install XBMC. If you don’t find it in any of the standard repositories or want to make sure you get the latest release version, then do this from the terminal window:
You might also want to install MythTV, or at least a MythTV frontend. See Links: A complete guide for setting up MythTV from start to finish for more information on that. Note that MythTV can be installed from the Ubuntu Software Center, and that’s the only recommended method, since they tend to offer a more stable version.
If you have an infrared remote control and infrared receiver (these generally come together as part of a package; check the XBMC forums to see which are recommended), run XBMC at least once and then run dpkg-reconfigure lirc from a command prompt (terminal window) to select your particular model of remote control.
You will likely want to be able to launch XBMC using the remote. As a PRELIMINARY way to accomplish this, we opened or created (can’t recall which) a file called .lircrc (note the leading dot character) in the user home directory and put the following lines in:
begin
prog = irexec
button = KEY_BLUE
config = xbmc --standalone &
repeat = 0
end
begin
prog = irexec
button = KEY_POWER
config = /usr/bin/gnome-session
repeat = 0
end
begin
prog = irexec
button = teletext
config = sudo shutdown -r now
repeat = 0
end
This starts XBMC if you push the blue button on the remote. It also returns to the desktop if you push the power button (however, it may leave whatever program you were in running in the background), and reboots the system if you push the teletext button, but for the latter to work, you must add the following line to the end of your /etc/sudoers file:
%admin ALL = NOPASSWD: /sbin/shutdown
EDIT: In later versions of Ubuntu the above line does not always work as shown, however, substituting the user name for %admin apparently does. So for example, if you had users named larry, moe, and curly on your system, you could do this (if you wanted all of them to be able to use the remote button to reboot the system):
larry ALL = NOPASSWD: /sbin/shutdown
moe ALL = NOPASSWD: /sbin/shutdown
curly ALL = NOPASSWD: /sbin/shutdown
Note that this is just to get you started — you can do more complex operations by running an external script rather than the selected program directly, to make your remote work the way you want it to.
By the way, the irexec program must be running for the above to work, so you can use the Ubuntu Startup Applications program to make it run at startup. You should run it with the -d option, e.g. irexec -d in order to make it run as a background process. Note that you need to do this even in newer versions of Ubuntu.
Startup Applications — Add Startup Program
You will probably want to set up one or more shared folders on your system so you can move videos, etc. into those folders. Be aware that you do have to enable file sharing for each folder you want to share. This is pretty straightforward in Ubuntu — select the folder you want to share, right click on the folder icon, click on “Sharing Options”, and then give the share a name and check the appropriate boxes:
Folder Sharing options
Check “Share this folder” and give the share a name (I called this one “shared”). Check “Allow others to create and delete files in this folder” even if you are going to require a valid login to do so, otherwise even you will not be able to copy files to that folder or delete existing ones from a remote location. Check “Guest access” if you want anyone on your local network to have access without the need to supply a user name and password.
If you are trying to get VNC screen sharing (in Ubuntu it’s called Desktop Sharing, but it’s actually VNC) to work, when setting up Desktop Sharing Preferences, make sure that “You must confirm each access to this machine” is UNchecked (it is checked by default).
Desktop Sharing Preferences – UNCHECK “You must confirm each access to this machine”
Then, use the CompizConfig Settings Manager (see How To Change The Settings Of Ubuntu Unity With CompizConfig Settings Manager) and uncheck all the options under “Effects” (except that “Window Decoration” is okay to keep). Apparently, the use of any visual effects is enough to make the remote desktop non-functional:
CompizConfig Settings Manager — Effects
The nice thing about this is that even if you have the overscan issue discussed below, when you access the shared Desktop you see the full screen including the top and bottom panels, so you don’t have to guess where you’re clicking! In theory, you could disconnect the keyboard and mouse from the Revo, and just use the Remote Desktop when you need to do system maintenance work, or whatever.
One major issue you may encounter when using a HDTV as the display device is something called “overscan” – that means the desktop is actually larger than the area shown by the HDTV display, meaning you can’t actually see your top panel, etc. While XBMC has a ways to correct for overscan, it’s better to correct it for the entire system. In recent Ubuntu versions, the NVidia drivers are installed when Ubuntu is installed (probably only if the installer detects you have NVidia graphics hardware), and the newer drivers do sometimes expose an Overscan Compensation slider that can be used to correct the problem:
NVIDIA X Server Settings (Overscan Compensation slider near bottom)
This slider doesn’t always appear for some reason, and even when it does, you really should try NOT to use it (except, perhaps, during initial setup and configuration) because if set to anything other that “0” it WILL degrade picture quality somewhat. The proper place to cure overscan is at the HDTV itself. Most HDTV sets have a setting that will fix overscan, but the problem is that there is no standard name for this setting — I’ve seen it called things like pixel-to-pixel, dot-to-dot, 1:1 display, exact image, etc. It’s often buried a submenu or two deep (remember that owner’s manual you got with your TV? Now might be a good time to dig it out!). I’ve found that if you look hard enough, most newer TV’s have this setting, although some do a pretty good job of hiding it (the Sharp LC-42SB45U being an extreme case – it won’t even display the option unless the timing of the signal you send meets certain specifications!). You really should try very hard to find this option, because it’s much better to correct the problem at the hardware end than by using any software method (that includes the software overscan correction built into XBMC) – you’ll get a sharper picture and quite likely fewer issues with video flickering, etc. Even if you have to resort to building an xorg.conf file to make it work, that’s better than trying to do software overscan compensation in the video driver or XBMC — use that method only as a last resort.
If your TV set just doesn’t have a setting such as the one mentioned above — and some don’t — there is a page of instructions to help fix the overscan problem here. We originally wanted this for the aforementioned Sharp LC-42SB45U TV and wasted a huge amount of time trying to find an overscan fix, and you can read what we finally came up with for that particular make and model TV only here: An overscan fix for the Sharp LC-42SB45U television set when connected to a computer with a Linux operating system (Ubuntu, etc.) (and if you have that model TV, it’s preferable to use the xorg.conf file given at that link rather than the Overscan Compensation slider). No matter what, you can see the full screen if you use the VNC/Desktop Sharing service mentioned above, and some have even resorted to using a little workaround to make the overscan less annoying, assuming you don’t find the workaround more annoying than the original problem! And for the more technically astute, it’s always possible to tinker with the ModeLine in xorg.conf (which, again, is preferable to using the Overscan Compensation slider).
Note that the following few paragraphs (up to, but not including, the one about HDMI audio issues) were applicable at the time this article was originally written, but are likely no longer valid due to updates in the nVidia driver and in Kodi (the new name for XBMC).
Irregardless of whether you have overscan issues, if (and ONLY if) you can see any flickering or “tearing” or other weirdness during video playback, it would probably be a good idea to follow the instructions one of these three posts: Either Howto achieve judder free perfectly synced playback at 23.97/59.94 Hz, XBMC and fixing the 24p issue, or HOW-TO setup XBMC and Linux with correct resolution (xorg.conf) (and I’d recommend them in that order — start with the first, and only go on to the second or third if you still have unresolved issues, except that if after trying the technique in the first link, you still see a bit of flicker during the playback of video files then I’d jump right to the third link — that’s the one that fixed it for us on one installation) — in those articles they tell you to modify /etc/X11/xorg.conf and add a couple of lines. I’d suggest a few additional modifications there, if not already mentioned in whichever article you used — under Section “Device” add one or both of these lines
The first of those lines is a “blinking cursor fix” and it’s supposed to help if you find an unwanted blinking cursor you can’t get rid of (I haven’t encountered that particular problem yet). The second line enables 1080p 24Hz mode for smoother playback of certain videos (probably most of them, actually). That line can actually go in either “Device” or “Screen” section – I added it to both just to be safe, but that’s probably overkill. Also, at the bottom of the xorg.conf file, add this:
That’s supposed to provide better H264 acceleration.
If you added the “DynamicTwinView” “false” option as shown above, and you know for a fact that your monitor supports 1920 x 1080 @ 60 Hz (you should be able to determine that if you followed the instructions in the aforementioned post) then that mode should become available in XBMC — in the XBMC GUI, go to Settings | System | Video Output to select your desired output mode, and see if that mode is available. If, for some reason it is still not available, you might be able to force the issue (you really should not need to do this if you started with the posts linked above, but I’ll leave this information here anyway in case someone needs it) – in order to do that, open a terminal window and do this:
cd /etc/X11/Xsession.d
sudo touch 45custom_xrandr-settings
sudo nano 45custom_xrandr-settings
Paste into this file the following lines, but take the parameters for the first line from the Modeline you created in the previous step, except use “1920x1080_60.00” instead of “1920×1080”. The first line below is an example (do not copy it verbatim, use the settings from your Modeline) but the second and third can be copied and used as is:
One other thing that might improve the video quality in XBMC is to go to Settings | Video | Playback settings and change the setting Adjust display refresh rate to match video to On start/stop (you could also try Always). This fix may be of particular help if you are trying to watch Live TV, or recorded TV from a PVR backend, and the picture doesn’t appear quite as sharp as it should. Leave Pause during refresh rate change set to Off. Obviously, this would be most noticeable if you are trying to view a 1080p source. In some areas you may need to play with the de-interlacing options as well, but that is beyond the scope of this article, and we didn’t find a need to do that.
If you are having audio issues when trying to send audio via HDMI, first of all open a terminal window and enter alsamixer and when it comes up press F6 to select your sound card (most likely HDA nVidia) and then make sure that none of the S/PDIF outputs are muted (this will me indicated by “MM” whereas an unmuted one will show “00”). Pay particular attention to S/PDIF 1 as it is often the culprit – use the arrow keys to select it and then press M to unmute it, then ESC to exit. I know this doesn’t make sense since you are trying to send audio out the HDMI port and not the optical audio port, but trust me, you need to do this. Then, if you are finding that audio is coming from the wrong speakers (center and LFE channels are mixed up with left and right surround channels) go to this page: HOW-TO:Remap HDMI audio on Gen 1 ION – Linux – I suggest using the settings under “1.3.1 ALSA Configuration” and below, but read the entire page first to get the full overview. Note that after following the instructions on that page, if you are also running the MythTV frontend you may have to set the audio to use ALSA:hdmi_direct and that this will NOT appear in the dropdown – you should first select one of the other compatible HDMI card options and then edit the Audio Output Device field to show ALSA:hdmi_direct. This is all necessary because the NVIDIA MCP79/7A HDMI hardware has incorrect channel mapping. This problem does NOT appear when using the S/PDIF (optical) output.
If you want to use a web browser to view videos that require the Flash plugin (such as many YouTube videos), particularly if you will be trying to view them in fullscreen mode, you should know that the Flash plugin will not use the Revo’s onboard nVidia graphics unless you tell it to. But, if you don’t do that the videos will most likely be too jerky to watch. So here is what you need to do from a Linux command prompt:
Then press CTRL+X followed by Enter to save the new file.
Note that this fix does not work absolutely perfectly, so you might still see some video issues now and then, and it might not work on all sites or in all browsers (it does work in Firefox, however). In many cases the video will be far more watchable than without the fix, but on some systems this fix could cause browser crashes and if those become frequent you may need to try removing the /etc/adobe/mms.cfg file. Also, note that this fix will only improve videos played using the Flash plugin.
If you need to (re)format a hard drive to use with your system, and you don’t want any wasted space on the drive, be sure to read this: Free Disk Space by Reducing Reserved Blocks
If you want your system to have a fixed IP address on your local network, click on the networking icon in the top panel (up and down arrows side by side), then Edit Connections, then find the connection you are using and edit it appropriately. For example, under the Wired tab I see Wired Connection 1, and if I click on that and then click the Edit button, I can then select the IPv4 Settings tab, change the method to Manual, and then enter the appropriate settings for my local network.
You may find that you need to go to the “Misc” section of /etc/samba/smb.conf and set domain master = no — otherwise you may find that certain network shares randomly disappear from other computers on your network. If you don’t have the problem of shares disappearing from other computers on your network, or if you don’t have any other servers or computers that are also trying to assert themselves as a master browser, then this may not be an issue for you.
If you want to reduce startup time when using Ubuntu or Mint (and you do not have more than one operating system installed), do this:
sudo nano /etc/default/grub
Then look for this line:
GRUB_TIMEOUT="10"
Change this line to read:
GRUB_TIMEOUT=0
Then follow the instructions at the top of the file: “If you change this file, run ‘update-grub’ afterwards to update.” This also must be done as root, so after you save the file and exit nano, do this:
sudo update-grub
If you allow the Update Manager to install certain types of updates (particularly nVidia driver updates) — and you should update your software when updates are available — you may find that XBMC won’t start up, but instead displays a message that stats with the words, “XBMC needs hardware accelerated OpenGL rendering.” Typically, simply rebooting the system will fix that issue.
If you are using the Perl script we posted a couple of years ago that monitors a Linksys or Sipura VoIP device and provides Caller ID popups when a call comes in, you may be interested to know that by adding one line to the Perl script and making some minor configuration modifications, you can also have Caller ID popups in XBMC. See our article BETA Perl script for Caller ID popups when using Linksys/Sipura devices for information. Alternately, if you have an Asterisk server, you can send Caller Id information to XBMC by adjusting the XBMC configuration as in the aforementioned article, and then adding a line to your Asterisk dial plan in the form:
Note that is all one line, and be sure to change the bold, italicized values to something appropriate for your configuration, and also be sure to see the aforementioned articles for XBMC configuration information and to get the phone.png icon.
If you would like to occasionally play music without the need to have the TV running, you might want to install a program called Audacious. The nice thing about Audacious is that it offers a LIRC plugin (under the General plugins section) and if you enable that, and then add a section to your .lircrc file (for an example, follow this link and then scroll down to the section “Configure Audacious(2) to use Lirc“), you can control the program using your remote.
Audacious Preferences
If you set Audacious to “Continue playback on startup” (under the Playback section of the preferences), and then create a .lircrc entry to start Audacious, you could use your remote to turn on Audacious and resume wherever it left off on your playlist. This is really beyond the scope of this article, but I just thought I’m mention it for those who have your Revo hooked up to a receiver and would like to be able to play audio without wasting electricity running a TV you’re not watching.
Addendum for those who wish to use Boxee under Ubuntu 12.04:
Boxee has discontinued support for desktop platforms, but you might be able to install the last Linux desktop version by following the instructions on this page to install Boxee (note particularly the unmet dependency that must also be installed), and then if you are using a MCE remote, you must also follow the instructions in this post to make the remote work correctly with Boxee.
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
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.
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.
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 September, 2009.
Cover of FreePBX 2.5 Powerful Telephony Solutions
FreePBX 2.5 Powerful Telephony Solutions by Alex Robar (Packt Publishing) explains how to set up, configure, and maintain a powerful VoIP PBX using FreePBX. For those not familiar with FreePBX, it’s a “front end” for the Asterisk PBX software. Asterisk can be thought of as the “engine” that runs the PBX, but FreePBX is the user interface. It basically saves you the effort of writing Asterisk configuration files and dial plans by hand. Instead, you enter all the requisite information in FreePBX’s web-based GUI, and then when you apply the configuration changes (by clicking an orange bar at the top of the screen), FreePBX (re)writes the Asterisk dial plan and configuration files on the fly. This means that making significant changes to the call flow within the PBX, or adding new extensions or trunks, can be accomplished in a matter of seconds or minutes. It also means that you can have a fully functional PBX up and running in a few hours (perhaps even less than an hour if you’re exceptionally quick and it’s not your first installation).
As I like to do in reviews, before I begin I’ll give you a thumbnail description of what’s in each chapter (condensed from information on the Packt Publishing web site):
Chapter 1: Installing FreePBX – Installing FreePBX on CentOS 5.2 or Ubuntu Server 8.10
Chapter 2: Module Maintenance – how to install and update modules
Chapter 3: Devices and Extensions – explains the difference between Extensions mode and DeviceAndUser mode, and explains how to set up extensions and users. Also explains the different types of endpoints, and how to set up voicemail for a user or extension
Chapter 4: Trunks – discusses trunk types, setting up a new trunk, and checking trunk status
Chapter 5: Basic Call Targets – explains various ways to terminate calls on a FreePBX system, including Extension and Voicemail, Ring Groups, Conferences, Day Night Mode, and Phonebook Directory
Chapter 6: Advanced Call Targets – discusses Queues, Time conditions, and the setup of an IVR (Digital Receptionist)
Chapter 7: Call Routing – discusses Inbound routing, Follow Me and the VmX Locater, and Outbound routing and Least Cost Routing
Chapter 8: Recording Calls – focuses on everything you need to know about recording calls that pass through a FreePBX system
Chapter 9: Personalizing Your PBX – discusses Custom Music on Hold, Custom voice prompts, Directory search options, Customizing feature codes, Callback, Direct Inward System Access (DISA), CallerID Lookup Sources, PIN Sets, Misc applications, and Misc Destinations
Chapter 10: System Protection, Backup and Restoration – how to protect your system against failure, discussing both hardware methods (a good UPS and redundancy) and backups and restoration
Chapter 11: Security and Access Control – explains how to upgrade your operating system and Asterisk, plus various ways to secure your system against attacks
There are also four appendices:
Appendix A: FreePBX Modules
Appendix B: Feature Codes
Appendix C: Voicemail.conf Options
Appendix D: Common Trunk Configurations
I’m coming from a slightly different place in my review of this book than with other books I’ve reviewed. In this case I’ve already very familiar with the subject material, having helped set up and configure a FreePBX system that belongs to another member of my family. I was a bit afraid that because I’m already so familiar with the subject, I’d find several glaring errors or oversights. Happily, that proved not to be the case – this book is a good, solid treatment of setting up and configuring a FreePBX system. In fact, the title should have been “How to set up and maintain a FreePBX system”, because that’s exactly what this book explains.
The first thing that impressed me about this book is that there was no “filler” material. Very often, with technical books, the author really only has about 75 to 100 pages of actual material, but because publishers like to publish books that have somewhere around a couple hundred pages, the author will flesh out the book with a history of the software, a profile of the developers, comparisons with competing products, and (if they are really desperate for material) a history of the Internet. 🙂 That is not the case here. After a very short preface, the author jumps right into the subject material, starting with how to install FreePBX and then continuing through subsequent chapters with virtually everything you need to know about configuration. While not every chapter may be meaningful to every reader (personally, I’ve never had the need to record a call — so far — but it’s nice to know that FreePBX can do it), the book at least touches on all the major features of FreePBX.
If I had to make one criticism of the book, it’s that in some places it reads a little bit too much like an instruction manual. And that’s not necessarily a bad thing, because FreePBX has badly needed a good manual to assist first time users in getting it set up and running. This is the manual that should have come with FreePBX. That said, the author really doesn’t touch some of the problems frequently encountered by new users. For example, in the discussion of SIP endpoints, he notes that “SIP can be problematic when traversing firewalls and other NAT devices” and that “Configuration can be particularly troublesome if both the endpoint and the FreePBX system are behind their own firewalls” (p. 44). And there he leaves the reader hanging. There is no discussion of how to overcome the problem, nor is there a pointer to the FreePBX FAQ’s or How-To’s anywhere in the book. While many readers may not encounter this issue, a fair number will, and it would have been nice if they’d been thrown a bone, if only in the form of a pointer to the FreePBX page that addresses the issue.
In my opinion, perhaps the biggest omission is in the discussion of Trunk setup in Chapter 4. This was really the only chapter in which I got the distinct feeling that the author may have been in just a bit over his head, and perhaps did not fully grasp the subject matter covered in the chapter. Not only are there errors in his examples of dial pattern usage (p. 81 – under no circumstances would you use two pipe characters in the same dial pattern, as is shown for some of the toll-free number examples), but when discussing IAX2 and SIP trunks (p. 83), only cursory information is given about how to populate the PEER details and USER details fields. Nor is it explained that with many commercial VoIP providers, the USER context and USER details fields are not used, and should be left blank. However, in the author’s defense, I suspect that I understand why this may have happened — there probably aren’t ten people on the face of the earth that can give you a full explanation of all the options that could possibly be used in the trunk PEER and USER details fields, and when and how each option should be used. Trunk configuration is probably the most difficult part of setting up FreePBX, precisely because there’s no definitive guide on how to do it correctly. In most cases, I suspect that finding the correct options to use with any particular provider is a matter of trial and error — you make educated guesses about which options might be needed and how they should be configured, and if you find a combination that works, perhaps you post it so that others can use it. Some of the known working trunk configuration settings appear in Appendix D of the book, but there are more sample configurations available at the FreePBX web site.
I only mention this because I was hopeful that maybe someone would finally provide a really good how-to on setting up FreePBX trunks, since this is something that almost always confounds new users, and even causes experienced users to get a few (more) gray hairs on occasion. Had I been writing such a book, and had I really understood the subject, I might have given several pages to the subject of trunk configuration in general, and PEER and USER details in particular, not just a few cursory paragraphs. On the other hand, most users will probably seek out a tested and working trunk configuration for whatever provider(s) they use. It’s not as though there isn’t any online help on the subject, but — and this is another minor criticism — for some reason the book barely mentions the availability of online help (for example, unless I missed it there is no specific mention of the FreePBX How-Tos that address several of the issues encountered by new users). This is why I say that at times the book reads like an instruction manual — it gives you all the basics, but seldom touches the “edge cases”, the little quirks and problems that may be encountered by a significant subset of users, but not by all.
However, I don’t want to leave you with the idea that this book is simply a rehash of information that could be found online — even if that were the case, it presents that information in a logical manner that is easily understandable by the reader. But, many essential functions of maintaining a FreePBX system happen outside of the FreePBX interface. For example, you cannot update your operating system or Asterisk from within the FreePBX GUI, but the book explains how to do both. Chapters 10 and 11 (on System Protection, Backup and Restoration, and Security and Access Control) deal with functions that are at least partially handled outside of FreePBX. In some instances the author provides useful shell scripts that automate particular tasks (for example, deleting old, outdated backups to avoid filling up the hard drive). And in many cases, the book does explain things that new users need to know, but might not know that they need to know — for example, the explanation of Codecs and the penalty involved (both in terms of system performance and call latency) in transcoding between codecs.
Anyway, the bottom line is this: Let’s say your boss wants you to set up a new office phone system using Asterisk, and gives you a couple of weeks to do it. If you have no prior experience with Asterisk, you will almost certainly want to use FreePBX (the alternative is writing dial plans and configuration files by hand, and trust me, you don’t want to do that unless you are the sort of person who enjoys writing source code for major projects, and even then you probably don’t want to do it if you’re under any sort of time deadline). And if you’re going to use FreePBX, and you don’t want to spend hours and even days ferreting out information on the Internet, you need this book. Get your boss to buy it (there’s even an e-book version if you need it right now), then just follow the instructions, chapter by chapter. In a few days time, you’ll be well on your way to becoming a FreePBX expert. That’s partly because FreePBX is so easy to use in the first place, but also because the book tells you pretty much everything you need to know, in a very understandable manner. If you get stuck, help is available at the FreePBX web site and at other various locations on the Internet.
If you are a long-time FreePBX user, you may find that you already know much of what’s in this book, but then again it might surprise you how much can still be learned. For example, I found several good suggestions for adding additional security to a FreePBX system in Chapter 11 of the book — and let’s face it, many of us are probably a bit lax about securing our systems to the greatest possible extent (and that could be a very costly mistake).
One other point I should make — as the title of the book implies, it deals with a particular version of FreePBX, namely version 2.5. Of course, as so often happens with a book about software, the ink is barely dry on the paper when a new version comes out. FreePBX 2.6 has already been offered as a release candidate, and beta versions of FreePBX 3.0 are being made available. From a user’s standpoint, version 2.6 will be nearly identical to 2.5 – there may be a few added options and such, but for the most part they are not things that you would need to worry about, or that would detract from the accuracy of this book. However, FreePBX 3.0 will be a major rewrite, but it’s only available in an early beta version, and unless you are an experimenter that wants to be on the bleeding edge, you don’t want it yet. Whenever you do move to FreePBX version 3.0 — and I’d be very surprised if a full release version is much closer than a year away — much of what you’ve learned about FreePBX 2.5 and subsequent versions will still be applicable (and also, I suspect that people will be using FreePBX 2.x versions for quite some time to come).
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.
Have you ever been in a situation where you want to extend a local network (or maybe an Internet connection) from one building to another that’s separated by some distance, say anywhere from several feet to a few hundred feet? Many people use wireless in this situation, and that’s a perfectly acceptable solution if it works, but it also brings with it a host of security issues. Any signal that is put into the airwaves is one that can potentially be intercepted, particularly if you’re not really familiar with wireless security. I’m not saying you should or should not use wireless, but I do know that some folks aren’t crazy about the idea. Also, there are distance limits on wireless links that can mean that no useable signal will be available where you want it.
Unfortunately, the only alternative to a wireless link between buildings is a physical link (if you ignore more esoteric alternatives that depend on both buildings getting their electrical service from the same power transformer) and there you have two choices, copper or fiber. Assuming you are going to bury a line between the two buildings, how do you know which to use?
I know there are people who would never recommend copper under any circumstances. The reason is that during electrical storms, there can be a difference in electrical potential between two buildings. This can cause serious amounts of current to flow, especially if lightning strikes nearby, damaging equipment (and in an extreme case, possibly even starting a fire). Even in cases where the equipment at the endpoints doesn’t seem damaged, the connection can turn very flakey after a lightning strike, with very high packet loss.
The only situation where you might get away with running underground Cat5e (or Cat 6, if you can find it) is to a very nearby building, and then only if you put very good approved lightning protection at both ends of the cable. The further away the building, the more important that the lightning protectors become (and if the buildings get electrical power from different sources, such as different electrical transformers, then the lightning protection becomes even more essential), and of course good lightning protection costs money. And even then, if lightning hits very close, it can fry the lightning protectors, meaning the Internet connection will likely be out of service until you can obtain and install replacement protectors.
One other problem to note: You have probably heard that the theoretical maximum distance for a run of Cat5e/6 cable on a wired network is 100 meters. That may be true indoors, in a dry environment. It’s not always true when the cable runs underground and/or is partially exposed to outdoor climatic conditions. On a run that’s close to the theoretical maximum in length, you may find that a connection that works beautifully during the cold winter months suddenly starts showing high packet loss during the heat and humidity of summer.
The alternative to Cat 5e/6 cable is fiber optic cable. Fiber is a great alternative because it uses glass fibers rather than copper wire to carry the signals. Since glass doesn’t conduct electricity, the only way lightning could ever affect it is in a direct strike, where it heats the ground so hot that the glass melts (this actually occasionally happens in areas with sand dunes, where the lightning creates glass sculptures by melting the sand into glass, but it’s very unlikely to happen on regular flat land).
The trouble with trying to use fiber is that just about everyone with any networking experience knows how to use Cat 5e or Cat 6 — you just plug it in to your equipment at each end, or if it doesn’t have plugs then you either use a tool to attach them, or your bring the wire to a modular jack and use a punchdown tool to make the connections (some lightning protectors have punchdown terminals as well). You can cut the cat 5e or 6 cable to the exact length you need. It’s something many people are familiar with, whereas fiber may as well have been pulled out of an alien spacecraft for all anyone (outside of those in the telecommunications industry) seems to know about it. If you go searching for pages on the Internet explaining how to install a fiber link between two buildings, good luck in finding anything useful!
Part of the probable reason there aren’t too many general how-tos on the subject is that there are so many variables — there are many types of fiber available, each of which is good for certain specific uses, with many different types of end connectors. And then you need equipment at each end to connect the fiber to the wired network, and you can’t just run down to the local office supply or big box electronics store to find that. But don’t despair, because I’m going to tell you one way to set up a short range fiber optic link. The caveat here is that I am by no means an expert on this — I’ve been involved in an installation ONCE, but I learned a lot in the process. Still, if you have questions that aren’t answered on this page, I’m probably not the guy to ask. But I figure that if you’re searching for online information on the subject, any information is better than none!
So let me start by telling you some things you need to know about fiber optic cable:
This fiber still worked! (Photo credit: Paul Timmins)
It comes in two varieties (that you are likely to encounter), singlemode and multimode. Singlemode fiber usually has a yellow jacket (plastic coating, like the insulation on a copper wire) whereas multimode cable generally has an orange jacket. For most short run applications (by that I mean distances measured in meters or feet, not kilometers or miles) you’ll use a paired multimode fiber (two fibers side by side, in a jacket that looks a bit like the type of electrical cord used with a table lamp, except the jacket is bright orange and it’s a lot smaller). If you’re a phone or cable company (or connecting to one) then you might have occasion to work with singlemode, but that’s not what we are talking about here. Singlemode is a lot more fragile than multimode – you can do this (photo at right) with multimode and it will probably still work (although anything remotely close to this tight of a bend is definitely NOT recommended – remember this is glass fiber that you’re bending, and if it breaks the cable becomes worthless!)
EDIT by TechNotes editor (March, 2021): Although the above paragraph was true when it was originally written, times change and now the orange jacketed cable, technically designated as OM, OM1, or OM2 cable, is basically obsolete. Nowadays you should probably be buying at least OM3 cable, or OM4 cable or OM5 cable if you can get it, which comes in different colors. More on that in a bit.
You can’t cut and splice fiber (unless you buy some really expen$ive supplies and equipment, and learn how to use them). You buy the length you need, with the connectors at each end already attached. If it’s too long, you coil up the excess (not TOO tightly) but you never cut it nor try to splice it, unless you have the specialized equipment that allows you to do so. If a cable is too short and you need to extend it, you can use a device called a fiber optic coupler (instead of “coupler” it may also be referred to as an “adapter” or “joiner”) which is a small plastic device that simply joins two fiber cables together so that the light from one travels into the other. These contain no electronics and therefore are very inexpensive, and can be used in just about any dry location, but there is a small amount of insertion loss that generally won’t matter unless you have an exceptionally long run of fiber or you use too many of them in one fiber run. There are both singlemode and multimode versions of these devices.
At each end, the fiber plugs into a device called a media converter. The media converter (or the SFP module that plugs into the converter — more on that in a moment) contains a laser, and a receiver. It transmits on one fiber of a pair, and receives on the other. The one thing you must never do, if you value your eyesight, is look into the laser while the unit is operating. That also means you can’t plug a fiber cable into the media converter, then look into the other end of the fiber to see if it’s working. If you think you might forget this important safety precaution, just try to remember that not looking into the laser is as important as not touching a live electrical line — and if that doesn’t scare you, take a course in reading Braille, because you’re probably going to need it.
It’s also possible to buy gigabit switches that can directly accept fiber. This eliminates the need for a separate media converter at one or both ends, but such switches tend to be a bit on the expensive side, although they also tend to offer more ports than most typical home switches (24 ports, for example). But there is sometimes a cost in terms of power consumption – for whatever reason, standalone media converters often tend to draw far less power than switches that have fiber ports. EDIT by TechNotes editor: As time marches on the prices of these are starting to drop AND the speeds of both the ports are increasing. For example, TRENDnet now offers a 9-Port Unmanaged 2.5G Switch, which includes one 10 GB SFP+ Port and eight 2.5 GB Ethernet ports, and it has been spotted for as low as $89.99 on a Black Friday sale. That price does not include a 10GBASE-SR SFP+ Multi Mode LC Module (model TEG-10GBSR) which supports distances up to 300m (984 feet), which will set you back an additional $30 or so. Back when this article was originally written, you paid more than that for just a standalone media converter and SFP module, and you only got 1 GB speed!
Fiber is somewhat fragile, and it can break (and be rendered useless) if it is subjected to too much strain. You can’t just pull it over a very long length without taping it to something else (that you’ll also be pulling) at regular intervals to relieve the strain. You can buy special, relatively inexpensive network pull string for the purpose, or if you don’t have any of that you can use any high tensile strength string (not twine, it breaks too easily, and avoid stretchy string because that sort of defeats the purpose – you want the string to help pull the fiber, not the other way around). The fiber I’ve seen needs to be inside something to protect it (no direct burial) – you can use cheap irrigation pipe for the purpose, as long as it’s large enough for the connectors at the ends to pull through (don’t try to be thrifty and undersize the pipe, but at the same time realize that fiber with the small LC connectors has plenty of room inside a standard one inch irrigation pipe, assuming you’re not pulling several multiple fiber pairs or other wires and cables). Also, you should use pulling lubricant on long pulls to prevent damage to the fiber jacket.
EDIT by TechNotes editor (March, 2021): Once again, the above was true when originally written, but now you can buy cable that is designated as “Outdoor Armored Duplex Fiber Optic Cable” that is not nearly as fragile as the orange stuff.
When you buy the fiber, it will have connectors attached at each end (at least it had better have, if you want to actually use it — don’t buy bulk cable that doesn’t have the connectors attached!). These connectors usually have two-letter designations. Popular types are LC (the smallest you’re likely to encounter, which makes it very popular these days), SC, and ST. The media converter (or switch) has to be able to accept the type of connectors your cable has. If your media converter has an ST connector and the cable has LC connectors, you’re out of luck. Sometimes you can buy cable with different connectors on each end, so be careful that it matches your media converters. If you find that your cable has one type of connector and your media converter expects another, you may be able to use a fiber optic coupler/adapter and then a very short fiber cable (sometimes referred to as a patch cable) that has the two different types of connectors on the two cable ends. So for example, if your cable is a duplex multimode type that has LC connectors but your media converter accepts ST connectors, you would need a LC-LC duplex multimode fiber optic cable adapter/coupler and then a LC to ST duplex multimode fiber patch cable. You just need to make sure that the patch cable has the same specifications as the cable you are trying to join it to.
A gigabit interface converter (GBIC) is a standard for transceivers, commonly used with Gigabit Ethernet and fibre channel. By offering a standard, hot swappable electrical interface, one gigabit ethernet port can support a wide range of physical media, from copper to long-wave single-mode optical fiber, at lengths of hundreds of kilometers.
The appeal of the GBIC standard in networking equipment, as opposed to fixed physical interface configurations, is its flexibility. Where multiple different optical technologies are in use, an administrator can purchase GBICs as needed, not in advance, and they can be the specific type needed for each link. This lowers the cost of the base system and gives the administrator far more flexibility. On the other hand if it is known that a switch will mostly have one port type (especially if that port type is copper) purchasing a switch with that port type built in will probably be cheaper and take up less space per port.
The GBIC standard is non-proprietary and is defined by the SFF Committee in document # SFF-8053i.
A variation of the GBIC called the mini-GBIC or SFP exists as well. It has the same functionality / modularity but in a smaller form factor.
SFP transceivers are designed to support SONET, Gigabit Ethernet, Fibre Channel, and other communications standards. The standard is expanding to SFP+ which will be able to support data rates up to 10.0 Gbit/s (that will include the data rates for 8 gigabit Fibre Channel, and 10GbE. SFP+ module versions for optics as well as copper are being introduced. In comparison to Xenpak, X2 or XFP type of modules, SFP+ modules leave some of the circuitry to be implemented on the host board instead of inside the module.[1])
Okay, in case you weren’t following along, a mini-GBIC, also known as a SFP, is a module that plugs into a media converter or a compatible switch. What this means to you is that you can buy a media converter, then plug in the SFP that matches the type of fiber and connectors that you have. So let’s say you have fiber with LC connectors – you get a SFP with LC connectors to match. Now suppose that at some point you need to replace that fiber with some that has ST connectors – you don’t have to throw out the entire media converter or switch, but instead you just get a new SFP. Not all media converters accept SFP’s, but many of the newer ones do. Also, not every manufacturer’s SFP will work with every media converter – if you buy an SFP you have to make sure it’s compatible with the media converter (or switch) that you own. It has become increasingly common to find fiber media converters sold with a compatible SFP as a bundle. (EDIT by TechNotes editor: Now there is an additional consideration: SFP+ ports and modules have become more common, so you have to make sure that if your media converter or switch has a SFP+ port, you use a SFP+ module with it.)
If you go the SFP route, you have to make sure of three things: That the connectors match the connectors on your fiber cable, that it’s intended for use with multimode rather than single-mode fiber, and that it’s for intermediate or short reach use (IR or SR — you may also find the designation SX or 1000Base-SX used to indicate a short to intermediate range SFP). In particular, you don’t want one with long reach optics because unless you use fiber attenuators you’ll overload and probably burn out the receiver at the other end (also, there’s a much greater chance of eye damage if you accidentally glance at the laser). To give you an idea of the difference, the short range optics are generally specified for runs up to a few hundred meters in length, while long range optics have distances specified in kilometers (sometimes as much as 80 km or more!).
So lets say that you want to run a fiber optic cable between two buildings that are a reasonably short distance apart — what do you need?
The first thing you need is a pipe or conduit of some kind between the two buildings. Irrigation pipe (the stuff you find at any home improvement store, or anyplace that sells underground lawn sprinkling supplies) is fine – remember you aren’t running anything electrical if all you are running is a fiber cable! The main thing is that the pipe or conduit that you use should be relatively smooth inside to minimize pulling resistance. Try to keep bends in the pipe to an absolute minimum. And yes, the pipe could be above ground as long as it’s sunlight resistant and not in a place subject to physical damage (but be aware that black pipe could get VERY hot in direct sunlight, so keep it out of the sun if at all possible). The purpose of the pipe or conduit is to protect the fiber. The pipe must be large enough for the connector (at the fiber cable’s end) to fit inside, with space to spare. If you have to splice sections of pipe together, the connectors may have a smaller inner diameter, so plan accordingly – you don’t want to get halfway through a pull and realize that the diameter at the splice point is too small to continue!
This article isn’t about burying pipe, but I will just suggest that you think about routing it far away from anyplace that people might be digging in the future, if at all possible — and if that’s not possible, then consider burying it as deep as possible, to minimize risk of backhoe failure (or on a farm, of getting plowed up!).
You need network pull string and electrical tape. The string must be longer than the fiber cable – if it’s twice as long then you could pull just the string through the pipe to use for pulling (a good shop vac and a small wad of paper tied to the end of the string is often enough to get the string started through the pipe), and still have enough left on the far end to tape the fiber cable to the string for the entire length. Do that every few feet, making sure that there’s a little slack in the fiber (not too much) when the string is pulled tight. Be sure to tape the leading end of the fiber connector (with the protective cap on) firmly to the string so it can’t try to flip over or do something equally undesirable during the pull. Note that if you are also pulling any kind of wire through the pipe on the same pull, you could tape the fiber to the wire rather than a string, assuming the wire is strong enough to not stretch during the pull.
EDIT by TechNotes editor (March, 2021): For short runs of cable that is designated as “Outdoor Armored Duplex Fiber Optic Cable” you may not need the pull string and tape, since that cable is less fragile than the orange fiber cable referenced in this article. But for longer runs, or if your pipe or conduit is undersized, I’d still consider using the pull string and tape, to avoid putting too much tension on the cable.
You need pulling lubricant — any electrical supply store sells this stuff. But note that this stuff can dissolve the adhesive on electrical tape (we found this out the hard way), so when you tape the cable to the string, try not to leave the adhesive side exposed. The trouble is that to really do it right you should use plenty of pulling lubricant, yet at the same time if you do, if you taped carelessly then you may have issues with the tape not holding as it should. That’s not a reason to apply less lubricant, but rather a reason to use a little extra tape and to make your tape wraps nice and tight, so the lube can’t get between the layers of tape (especially at the very start of the pull).
We used some blue gel stuff called Ideal Aqua-Gel II and used a paintbrush to apply it liberally to the fiber cable, after first using a funnel to dump some down the pipe. You can get a gallon pail of this stuff for between $15 and $20 at most electrical supply stores (the places the electricians shop), though you might wind up with another brand. We found that a gallon was really excessive, we could have easily got by with a quart of the stuff (on a 100-meter pull). On the other hand, it was much easier to dip a paint brush into the gallon pail, then slop it onto the fiber cable and down the pipe. You really don’t want to be stingy with it, since friction in the pipe can damage the fiber jacket.
EDIT by TechNotes editor (March, 2021): If you are using cable that is designated as “Outdoor Armored Duplex Fiber Optic Cable” and the run is short, you may not actually need the pulling lubricant, but it is always a good idea to reduce friction.
You need the fiber cable itself. The type of multimedia fiber cable that we are talking about here comes on a ridiculously small spool (and to me, it always looks larger in photos than it really is, which for years led me to think that it wouldn’t fit through the existing pipe that was used in this situation) — this is what 100 meters of dual fiber looked like before the bubble wrap was removed:
Fiber cable with LC connectors
The fiber we used was described as “Advanced Interconnect 100 Meter LC-LC Duplex MultiMode Fiber Optic Cable. This Advanced Interconnect cable part number 038-001-964 REV A. Cable is 50/125 OFNP Micron Fiber.” It was obtained from eBay seller isellcables. If you are wondering what a dual LC connector looks like, there is a good photo here. Note that the connector comes with a protective cap, which should be left in place during the pulling process.
EDIT by TechNotes editor (March, 2021): As mentioned earlier, this orange jacketed fiber cable is now considered old technology. What you probably want to use is cable designated as “Outdoor Armored Duplex Fiber Optic Cable” and OM3 or better. Strictly as an example (this is not a recommendation), in 2021 Amazon sells a product called Jeirdus 100Meters 328ft LC to LC 10G OM3 Outdoor Armored Duplex Fiber Optic Cable Jumper Optical Patch Cord Multimode 50/125 100M LC-LC for $128, with other lengths from 5 meters to 300 meters available. Something like that would definitely be preferable to the unprotected orange jacketed cable for outdoor runs, although I would note that because the cable is armored that means it could conduct electricity, even though the fiber connections at each end would still be electrically isolated. For additional electrical isolation you could add a length of unarmored cable at each end, using a LC-LC duplex multimode fiber optic cable adapter/coupler to join the cables together, but you would need to make sure the fiber optic cables you are joining have the same specifications (in particular, don’t connect singlemode to multimode cable). In case you are wondering, if you have already run the older technology fiber and now want to upgrade (from a 1 GB to a 10 GB connection, for example) you probably don’t need to run new fiber as long as the old stuff is still in good physical condition. The old orange-jacketed fiber cable seems to handle 10 GB just fine, though there may be unique situations where that is not the case.
You need a couple of fiber media converters, one for each end, and if they use SFP modules you’ll need a couple of those as well. They look like this:
Fiber media converterFiber media converter
Notice (if you can actually see it in these photos) that the fiber cable is plugged into the SFP module, which in turn is plugged into the media converter — here’s an enlarged and enhanced closeup, where you can just see the end of the SFP (the small chrome part) sticking out of the media converter:
Fiber connects to SFP module, inserted into media converter
This media converter was described on eBay as “Gigabit Fiber media converter multimode MM, 1000Base SX” and “The FIB1-1000ES MM is a Gigabit Ethernet copper to multimode 850nm LC connector fiber media converter. It has an SFP (Small Form Pluggable) slot occupied by an MM 850nm multimode module, Ethernet 1000Base-SX compatible. The Copper interface is an auto negotiating 10/100/1000 BaseT RJ45 interface with auto MDI/MDI-X detection. …” I would point out that it’s important that it actually says 10/100/1000 BaseT if your network runs at anything less than 1000BaseT speeds, because not all media converters will handle multiple speeds or speed conversions. As Paul Timmins told me, “it’s VERY possible for something to ONLY support Gigabit. When you get down to media converter territory, the reason they get cheaper is they have less guts to convert stuff between 1000T and 100T (you need buffers, ability to send gigabit pause frames when your buffers are full, etc).”
EDIT by TechNotes editor (March, 2021): As time has passed newer equipment has become available that can handle speeds up to 10 Gigabits. That may be serious overkill for most home users, but if you are doing heavy video editing or anything else that produces very large files, you may want to look into the higher speed equipment.
As it happened, this eBay sale included a LC SFP with each converter, so those didn’t have to be purchased separately. The seller on these was sales_fo4all. If you search on Amazon or eBay using a phrase such as Fiber Media Converter LC Multi-Mode you should be able to find something similar, possibly at a better price than what we paid.
Below is an individual SFP in its packaging – you can’t see the model number but it’s SFM-7000-S85, which is described as a “1000Base-SX, multi-mode, 550m, 850nm SFP transceiver” and additionally, that “The capacity of SFM-7000-S85 module is 1.25Gbps (Gigabit rate). The transceiver extended range allows operation on either 50/125um or 62.5/125um multi-mode fiber for up to 550m distance. (Note: for 62.5/125um fiber, maximum operating distance is only 275m).” Since our cable was the 50/125 stuff, we could have gone a much greater distance (about 1800 feet) if necessary, and if we’d had a cable that long! In the picture below, the black part on the left is a small protective cap that is removed before you plug in the fiber cable.
SFP module
A better picture of a SFP module can be found here. If you are observant, you may note that both the fiber converter and the SFP module shown above are made by the same company (CTC Union Technonlogies in this case). You may wonder, as I did, if you can use one manufacturer’s SFP with a different manufacturer’s media converter or SFP-compatible switch. According to Paul Timmins, “they’re theoretically universal but there’s absolutely nothing preventing them from vendor lockin (they’re active devices with internal serial numbers, etc, that help negotiate the capabilities of the optics with the device itself, and many vendors will refuse to work with another vendor’s GBIC/SFP).” I’m also told that a certain big name networking equipment manufacturer takes measures to prevent you from using competitor’s SFPs (which can often be overridden with undocumented commands). So if at all possible, when buying new equipment try to buy the media converter and SFP module as a matched set, or failing that, make sure that both the media converter and the SFP module come from the same manufacturer (unless there is some guarantee of compatibility, or the cost difference is great enough that you are willing to take the gamble that it will work). Then all you have to worry about is whether the SFP has the correct connectors to match your cable, and whether it’s the correct power level for the range you are using (again, don’t get anything that’s rated for use with cables of multiple kilometers in length, unless your cable really is that long!).
After you pull the fiber cable, connecting everything up is fairly straightforward. The SFP plugs into the media converter or switch, and the fiber cable plugs into the SFP. You then simply connect the media converters to your existing network at both ends using a Cat 5e or Cat 6 patch cable. Then apply the power to the media converters at both ends (if you don’t apply the power until everything is plugged in, you can’t accidentally look into the laser!).
If you happen to get the type of media converters shown above, you may notice that there are dip switches on the unit. There are for manually setting the port speed, and full or half duplex mode. We left these in the factory default position (all up, which is indicated as “UDP/NWAY” mode) and it works fine. Another thing you might wonder is whether you can connect a computer directly to the media converter at the distant end of the connection, and of course the answer is yes, though many people will prefer to connect a switch so that multiple devices can be used. And remember, you do have the option to buy a switch that accepts one or more SFP modules directly, which may mean you won’t need the standalone media converter at that end — but before you do, check the power requirements. As mentioned above, I found that such switches tended to be a bit power-hungry compared to the standalone media converters shown above.
What about the cost?
The upfront cost of running fiber is more expensive than using Cat 5e or Cat 6 underground, although if you add in the cost of good lightning protection at both ends (or replacing equipment that gets fried by lightning if you don’t use great lightning protection) then the cost difference is less significant. Today you can get 100 meters of fiber optic cable on eBay for about $80, including USPS Priority Mail shipping. The media converters and SFPs are still the expensive items — as I write this, they are going for $127 per set (media converter and SFP) on eBay, plus shipping. Add in the price of incidentals (pipe or conduit, pulling lubricant, network pull string) and you can expect to pay around $400 or perhaps a bit more for a 100-meter run (less if you can re-use existing pipe or conduit, more if you have to pay someone to dig a trench or otherwise run the cable through a difficult place). Of course you would have these same costs when running Cat 5e or Cat 6 underground, except for the media converters, so as a rough rule of thumb the price difference is the added price of the media converters and SFPs, minus the cost of the excellent lightning protection that you won’t need because fiber optic cable doesn’t conduct electricity.
EDIT by TechNotes editor (July, 2020 and March, 2021): It has taken years for prices to drop on these units but it appears the shift toward lower prices has finally begun. Amazon now sells some fiber media converters and SPF’s at significantly lower prices, for example you can get a Gigabit Ethernet Multi-Mode LC Fiber Media Converter (SFP SX Transceiver Included), up to 550M, 10/100/1000Base-Tx to 1000Base-SX from Amazon for under $40 at the time of this edit. We have not tested this item, but think it would work in the same way as the media converter and SPF shown above. Be sure to read the reviews before buying any item, since you probably don’t want to buy units that have a tendency to fail after a few weeks or months of use. You can also now buy fiber media converters and SPF’s rated at 10 Gigabits, though as you may expect the prices for those will be higher. And also, switches that directly accept SPF’s (eliminating the need for a separate standalone Fiber Media Converter) are now starting to become more common, as mentioned earlier you may now be able to obtain a switch with eight 2.5 GB Ethernet ports and one 10 GB SPF+ port for under $100 if you buy it when it is on sale.
And it finally looks like the price of fiber optic cable has started to fall just a bit as well, a 100 Meter Multimode Duplex Fiber Optic Cable (50/125) – LC to LC – Orange purchased from Amazon will run you just a bit under $65, and you may even be able to find better deals than that on eBay or from some other source. But as noted above, you would probably be much better off to use cable that is designated as “Outdoor Armored Duplex Fiber Optic Cable” which although a bit more expensive, should be far more resistant to damage, and will probably last longer. And even if you don’t go the armored cable route, if you are running new cable you would do well to consider avoiding the older technology orange cable shown in this article, in favor of cable designated as OM3 or OM4, or better if available (but if you already have the older stuff you don’t necessarily need to replace it). (End of edit.)
I figure that in practice, the fiber install will cost anywhere from about the same amount to an extra $150 compared to an equivalent Cat 5e/Cat 6 install (again, we’re talking a 100-meter run here), but it will be worth it the next time you have an intense electrical storm nearby and realize that you’re probably not going to lose a lightning protector, computer, or router because of a surge coming in over the network cable. It will also be worth it if the run is long enough that every hot and humid day results in a degraded connection when using Cat 5e or Cat 6 underground.
I do expect that the use of fiber will become more common in the future, since we will want ever-faster connections and there is a theoretical maximum on connection speed using copper. At some point, I expect the prices of fiber equipment to fall (the day they start selling it in the big office supply chain stores is the day you will see the price drop to more reasonable levels). But for now, the prices aren’t that unreasonable (especially compared to a few years ago). By the way, if you want to be the next millionaire, design a system that allows people to reliably attach their own connectors to bulk fiber cable, and that sells for under $100. It’s ridiculous that anyone should have to pay four-figure sums just to be able to attach ends to fiber cable.
One other thing I think would help with fiber acceptance is to make an ultra-strong fiber cable that’s designed for difficult pulls – something with enough integral strength that you could pull the cable itself and not have to worry about breaking the glass fibers, and with a thick enough and tough enough jacket to withstand pulls over rough or uneven surfaces. Basically, fiber cable that could take a lot of abuse without breaking (not that the stuff we used is all that fragile, but still, it would be nice to not have to worry that it can be easily damaged, especially when you’re paying around sixty to seventy bucks for a 100-meter roll).
Thanks and acknowledgements
I want to thank Paul Timmins (the creator of the very useful TelcoData.us Telecommunications Database) for his help and patience in helping me understand all this stuff. This article could not have been written without his assistance. Also I want to thank my oldest son, who probably doesn’t want me to mention him by name, for his help and for letting me photograph some of the components in a recent installation.
My purpose in writing this article was to try and help de-mystify some aspects of using fiber optic cable in place of Cat 5e/6 for runs between nearby buildings. Again, I am NOT an expert in this, and I may have left some questions unanswered. If you have questions or need clarification on some point, or if you see where I’ve made a glaring error, feel free to leave a comment. If I don’t respond, it probably means that I don’t know the answer, but maybe someone else with more expertise than I will chime in and help.
I recently had the experience of trying to help someone make a 
Recent Comments