Category Archives: Telephone

Read this before you pay $10 to Obihai for support

 

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

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

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

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

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

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

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

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

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

m.

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

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

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

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

How to set up an alternate SIP port (other than 5060) using Webmin

One problem that some VoIP users are experiencing these days is that they have trouble connecting to their home Asterisk, FreeSWITCH, YATE, or other software PBX server, but only when using certain ISP’s.  One suspicion is that certain ISP’s that offer their own VoIP or traditional landline service attempt to mess with packets using the common SIP port 5060, hoping customers will think that VoIP is unreliable and will subscribe to the company’s overpriced offering instead (see this thread at BroadbandReports.com).

There are various ways to enable an alternate SIP port on the server (in addition to the usual port 5060) but if you are using Webmin to manage your firewall, here’s an easy way, in just three steps:

Step 1:

If you use Webmin to manage your firewall, then you already know how to get to the Linux Firewall page.  So go there and select the Network Address Translation (nat) table in the dropdown at the top of the page.  Then when the page changes, click the topmost Add Rule button (in the Packets before routing (PREROUTING) section):

SIP Port Forwarding 1

Step 2:

Now you should see this page. The items you need to change are indicated by the red ovals.  The Destination TCP or UDP port is set to 7654 in this example, but don’t use that.  Pick your own unique port; just make sure that it’s not used by anything else on the server already.  And yes, you really do put the alternate SIP port you want to use in the Destination setting; it may not make intuitive sense but that’s just how it is.  Avoid using ports in the range 10000 through 20000 because those are used for RTP traffic, and avoid ports below 1024 because those are protected ports that are reserved by the system.  There are also other ports you should avoid (those used by other software on your system) but if you don’t know how to find ports in use on your system, a bit of time with a search engine will lead you to several pages that show you how to detect already active ports.  It can vary a bit depending on your operating system, and it’s beyond the scope of this article.

SIP traffic is UDP only, not TCP (there may be rare exceptions but most software PBX’s use UDP by default).  If by some very odd chance you are using TCP for SIP traffic (why?!?) then you will need to specify that under the Network Protocol item.  Also, note that the incoming interface is set to eth0 in this example – Webmin will usually show the correct one by default, but you want to select the interface used by incoming SIP traffic if you happen to have more than one.  Don’t forget to click Save when you’re finished.

SIP Port Forwarding 2

Step 3:

After you have saved the page you should be back at the page you came from, and it should now show your new forwarding rule.  If it does, just click Apply Configuration at the bottom of the page to make it active:

SIP Port Forwarding 3One other thing you might need to to is add a rule on the main Linux Firewall page allowing incoming traffic on your selected alternate port, if you have a restrictive firewall that blocks most traffic by default.  Try it first without doing that, but if your clients can’t connect on the alternate port, just be aware that you may need to do that before they will be able to connect.  For more security, you can enable access to your SIP ports only from specific IP addresses, if your remote clients are at fixed IP addresses.

Now you should be able to change the port number on your SIP endpoints from the default 5060 to your alternate port.  Of course I can’t guarantee it will always work, but if you try it and suddenly find that your SIP connections become far more reliable, you might want to leave a comment, and mention the ISP that you suspect might be messing with SIP traffic.

By the way, if you are NOT using Webmin to manage your firewall, and have iptables installed, then all you should need to do is enter these two lines from a command prompt (replace 7654 with your chosen alternate port).  But I strongly caution you NOT to do this if you are using Webmin to manage your firewall:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 7654 -j REDIRECT --to-ports 5060
/etc/init.d/iptables save

Asterisk on a Raspberry Pi – which distribution is best?

Portions of this article were UPDATED July 20, 2016, mostly to include information about Raspivo.

To the best of our knowledge there are five projects that will allow you to run a PBX on a Raspberry Pi. They are:

In this discussion we are only going to consider the first four, because FusionPBX runs on top of FreeSWITCH, not Asterisk. And we have nothing against FreeSWITCH, but it’s never been big among home users and experimenters. Perhaps that should change, but for now we just want to consider the Asterisk-based distributions.

It does not seem as though µElastix ever really caught on with a significant group of English-speaking users, and therefore it would be difficult to offer any sort of opinion. But we will note that new users and those not all that familiar with Linux may have a bit more trouble with the installation process, since there is no image file provided as is the case for some other distributions. One potential advantage of µElastix is that it will run on a Raspberry Pi, PicoSam, or Mcuzone, though you are not likely to run into the latter two boards anywhere in North America.

As for Incredible PBX, this takes the typical Nerd Vittles/PBX in a Flash “throw in everything but the kitchen sink” approach, but then offers this ominous-sounding advice:

Here’s everything you need to know about security for Incredible Pi:

1. ALWAYS RUN INCREDIBLE PI BEHIND A SECURE HARDWARE-BASED FIREWALL/ROUTER
2. NEVER EXPOSE ANY INCREDIBLE PI PORTS DIRECTLY TO THE INTERNET
3. NEVER MAP INBOUND INTERNET PORTS FROM YOUR FIREWALL TO INCREDIBLE PI

What this basically means is that you can’t have any off-site extensions that register with your Asterisk server, if you heed their warning.  Well, you CAN, but not in any way that’s convenient for end users.  The problem apparently is that a few years ago someone connected with that project got hold of an article or two where someone got a huge phone bill by having an unsecured PBX, and had a major freakout about it.  There were probably several security failures associated with those incidents, but here is our question:  Since nobody in ANY other PBX project we’ve ever encountered gives advice like this, does this mean that Incredible PBX is incredibly insecure by design, and the only way to properly secure it is to take extraordinary steps such as these?

We’re not saying that all of this advice is out of line – the first point is probably a very good idea whenever possible – but most home users will be doing that anyway.  But it’s #3 we particularly take issue with.  If you want to have any external extensions, you pretty much need to forward UDP ports 5060 and 10000-20000 to your Asterisk server.  And the Incredible PBX people specifically tell you not to do that, rather than recognizing that for some users that is simply not a viable option.

The other issue we have with Incredible PBX is that it includes a lot of what we would consider frivolous add-ons.  The main reason people generally install a PBX is because they want to use it to make phone calls, and perform a few other basic functions such as record voicemail, let callers select a destination from an auto-attendant, and so on.  All of these basic functions are provided by FreePBX, and all the other add-ons are pretty much useless unless you are just installing a PBX to play with features.  We can just about guarantee you that 99 percent of your users will not care that they can dial a code and get tide reports, or some similar nonsense.  On a regular server that has a lot of CPU power and storage space, having a bunch of extras may not be a problem.  On a Raspberry Pi, however, you are probably going to want a lean, trim installation that doesn’t get in the way of the basic functionality of a PBX.

I’ve seen reports in mid-2016 that Incredible PBX will soon (and perhaps already does) offer a menu at installation where you can select which features you want. However you will need to choose carefully because if you reject an option and then later decide you want it, you might need to reinstall from scratch to get it. New users might not know which features are actually useful and which are needless bloat, but at least it appears some effort is underway to stop forcing users to take all or nothing.

Raspivo is based on XiVO, which has been around for a while but was relatively unknown in the English-speaking world until fairly recently. However it has generated a lot of interest due to users desiring an alternative to FreePBX, which seems to be getting less “free” (in all senses of that word) as time goes by. There is a discussion about XiVO on DSLReports that you may wish to read, which in turn contains several other useful links. My understanding is that the “official” English language translation of the installation instructions are somewhat out of date, so you may find that RonR’s instructions on DSLReports are easier to follow. Like FreePBX, XiVO is a GUI interface for Asterisk, so any custom dialplan you have written for another build of Asterisk should be usable (perhaps with minor modification) in Raspivo. It appears that you must have at least a Raspberry Pi 2 or newer to run Raspivo.

If you have no experience at all with software PBX’s and are just getting your feet wet, but you are not unfamiliar with programming, XiVO is the one I’d suggest. It makes repetitive tasks easier but doesn’t get in your way when you want to customize your system to the same degree that FreePBX does. However if you just want everything to be as easy as possible, and you never want to do any dialplan customizations (or only very limited ones), then you may want to consider Asterisk for Raspberry Pi, also known as RasPBX.

The RasPBX distribution includes Asterisk and FreePBX, with additional scripts that will optionally let you install HylaFAX and/or Fail2Ban. There is also a related version of this software for the BeagleBone Black. This software is relatively easy to install, comes with no ominous security warnings, and doesn’t include a lot of “bloatware”, which we think is a definite advantage. They also have a semi-active discussion forum where you can find several installation and usage tips. And it is possible to run RasPBX from an External USB HDD or Thumb Drive, in case you are worried that running a PBX off of an SD card might not be reliable, although there are ways to minimize writes to the SD card if you prefer not to have the added power drain of another device.

We realize that none of these distributions are absolutely perfect, and everyone will have their own reasons for picking one over another. The PBX in a Flash forum used to include a Raspberry Pi board, but it was apparently lost in their “Great server crash of 2013”, and they never bothered to reinstate it. So it seems that for them, the Raspberry Pi is just one of many platforms they are attempting to support, and it does not appear to us that they are making much of an attempt to optimize their software specifically for the Raspberry Pi. We might receive a few less than gracious comments for saying that, but that’s simply our observation, and others are free to disagree – we just recall the old saying, “Jack of all trades, master of none” and feel it might apply in the case of putting out a version of Incredible PBX for the Raspberry Pi that includes pretty much everything that the versions intended for larger servers include. For performance reasons, we’d prefer to stick with a distribution designed for the Raspberry Pi from the ground up, and therefore our preference has always been Asterisk for Raspberry Pi / RasPBX, though nowadays we’d suggest that anyone that wants to have complete control over their system might also consider Raspivo. Just be aware that the learning curve with Raspivo might be a bit steeper.

If you disagree, feel free to try any of the other distributions mentioned. That’s the nice thing about having choices – you can try various programs until you find one that meets your needs, and maybe even your wants.

One final point – since this article was originally written in 2013, new versions of the Raspberry Pi have appeared, and some of the above-mentioned software may have been updated to only run on newer models. Or they may run, but only painfully slowly, if you have an original Raspberry Pi. In particular, it appears that Raspivo will only run on the Raspberry Pi 2 or newer. So if you have a first-generation Raspberry Pi, pay attention to the system requirements for the software you are downloading, because you might need to seek out an alternate or older version of the software.

Link: How to Install Asterisk 11 in RHEL/CentOS/Fedora and Ubuntu/Debian/Linux Mint

Asterisk is an Open Source software PBX (Private Branch Exchange), developed by Mark Specer of Digium. It allows you to make calls to one another which may have connected to other PSTN (Public Switched Telephone Network) and Voice over Internet Protocol (VoIP). Asterisk runs on Linux, BSD, MacOSX and others. Having built-in features like voicemail, conferencing, IVR, queuing etc.

In this article, we are going to see a basic installation and working of Asterisk 11 in RHEL 6.4/6.3/6.2/6.1/6.0, CentOS 6.4/6.3/6.2/6.1/6.0, Fedora 18,17,16, Ubuntu 12.10/12.04/11.10, Linux Mint 14/13 and Debian Linux Operating Systems.

How to Install Asterisk 11 in RHEL/CentOS/Fedora and Ubuntu/Debian/Linux Mint (TecMint.com)

Link to POSSIBLE method of porting a landline phone number to Google Voice for free (well, except for the $20 that Google Voice charges)

 

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

Google Voice will only allow you to port cell phone numbers to their service (don’t ask ME why — seems stupid, but that’s their rule) so if you want to port a landline number, you first have to temporarily port it to a cell phone provider, then from there port it to Google Voice. Most of the published methods that I have seen for doing this involve paying out some small sum (usually around $20) to get a “disposable” cell phone (so after adding the $20 that Google Voice changes to do the port you are out almost $40), however I just stumbled across a thread that suggests it may be possible to do it for free, IF you have (or can borrow) an old Verizon or Page Plus cell phone that’s not currently being used.  Note this may not work in all areas (there are still areas of the country where Google Voice can’t port numbers) and I don’t guarantee it in any case because I haven’t personally tried it, but if you’ve been thinking of porting your landline number to Google Voice, this MIGHT save you a few bucks:

Post on DansDeals.com Forums

Again, although it’s not clear from this thread, Google Voice will still charge you $20 to do the port, but if you can get this to work it could save you some money.  Note that if you are served by some Podunk (independent) telephone company there’s a good chance it won’t work, so keep that in mind if losing your number would be a major catastrophe for you.

Review of FreeSWITCH Cookbook by Anthony Minessale, Michael S Collins, Darren Schreiber, Raymond Chandler (Packt Publishing)

 

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

The FreeSWITCH Cookbook is the second book from Packt Publishing on the subject of FreeSWITCH, which in my opinion may someday soon be the “telephony software engine” that replaces Asterisk in popularity. I’ve previously reviewed the earlier book, FreeSWITCH 1.0.6, and this book builds on that one. If you know nothing at all about FreeSWITCH, you’ll probably want to start with the earlier book, because it gives you all the basics.  The publisher was kind enough to send me a complementary copy of the new book for review purposes.

This book, as the name implies, is a “cookbook” in that it gives “recipes” for how to do certain tasks. Just as an actual cookbook presupposes certain knowledge (that you know how to operate an oven; the difference between certain measuring units, etc.) this book tends to start with the assumption that you already have a grasp of how to set up FreeSWITCH, but you may need examples of the configuration necessary to perform certain tasks. And, that’s what this book gives you. The idea, I think, is that if even one of the “recipes” saves you a couple of hours of head-scratching and trying to figure out how to do something, then that justifies the cost of the book.

Normally in this type of review I would list the chapters, but in the case of this book you’ll probably want to know what’s in each chapter. So, here is the complete Table of Contents from the Packt Publishing web site:

  • Preface
  • Chapter 1: Routing Calls
    • Introduction
    • Internal calls
    • Incoming DID calls
    • Outgoing calls
    • Ringing multiple endpoints simultaneously
    • Ringing multiple endpoints sequentially (simple failover)
    • Advanced multiple endpoint calling with enterprise originate
    • Time of day routing
    • Manipulating To: headers on registered endpoints to reflect DID numbers
  • Chapter 2: Connecting Telephones and Service Providers
    • Introduction
    • Configuring a SIP phone to register with FreeSWITCH
    • Connecting audio devices with PortAudio
    • Using FreeSWITCH as a softphone
    • Configuring a SIP gateway
    • Configuring Google Voice
    • Codec configuration
  • Chapter 3: Processing Call Detail Records (available as a sample chapter in PDF format)
    • Introduction
    • Using CSV CDRs
    • Using XML CDRs
    • Inserting CDRs into a backend database
    • Using a web server to handle XML CDRs
    • Using the event socket to handle CDRs
  • Chapter 4: External Control
    • Introduction
    • Getting familiar with the fs_cli interface
    • Setting up the event socket library
    • Establishing an inbound event socket connection
    • Establishing an outbound event socket connection
    • Using fs_ivrd to manage outbound connections
    • Filtering events
    • Launching a call with an inbound event socket connection
    • Using the ESL connection object for call control
    • Using the built-in web interface
  • Chapter 5: PBX Functionality
    • Introduction
    • Creating users
    • Accessing voicemail
    • Company directory
    • Using phrase macros to build sound prompts
    • Creating XML IVR menus
    • Music on hold
    • Creating conferences
    • Sending faxes
    • Receiving faxes
    • Basic text-to-speech with mod_flite
    • Advanced text-to-speech with mod_tts_commandline
    • Listening to live calls with telecast
    • Recording calls
  • Index

As you can see, the order progresses from the basics (setting up your extensions, and inbound and outbound routing) to the sort of things you might want to do in a more full-featured PBX. Chapter 4 in particular will be of interest to many developers. I’ll quote from the introduction to that chapter:

One of the most powerful features of FreeSWITCH is the ability to connect to it and control it from an external resource. This is made possible by the powerful FreeSWITCH event system and its connection to the outside world: the event socket. The event socket interface is a simple TCP-based connection that programmers can use to connect to the inner-workings of a FreeSWITCH server. Furthermore, the FreeSWITCH developers have also created the Event Socket Library (ESL), which is an abstraction layer to make programming with the event socket a lot simpler. The following languages are supported by ESL:

  • C/C++
  • Lua
  • Perl
  • PHP
  • Python
  • Ruby
  • TCL

Keep in mind that the ESL is only an abstraction library—you can connect to the event socket with any socket-capable application, including telnet!

The tips in this chapter will focus most of their attention on using the event socket for some common use cases. The last tip, though, will introduce a particularly interesting way to connect to FreeSWITCH externally without using the event socket, namely, using the built-in web server that is enabled when you install mod_xml_rpc. Regardless of how you wish to control FreeSWITCH, it is highly recommended that you read the first recipe in this chapter, Getting familiar with the fs_cli interface, as this will serve you well in all aspects of working with FreeSWITCH.

This, of course, is somewhat analogous to controlling Asterisk via Asterisk Gateway Interface programming, but it appears that you get more functionality in FreeSWITCH, and more languages are supported.

I have said on many occasions that I am not a programmer, so in one sense I’m not exactly the target audience for this book.  However, I know just enough about coding to be able to appreciate when a book lays out examples in a clear, easy-to-understand manner, with enough comments for you to “get” what the author is trying to explain to you.  Personally, if I could just get over my hurdle of not fully grasping XML (which is actually strange, because I have no problem understanding basic HTML, which is very similar), I think that this book would be a lot more useful to me in understanding how to do things in FreeSWITCH.  I sort of “get” Asterisk dialplans a little bit, but for some odd reason XML is not nearly as understandable to me.  I guess everyone’s mind works a little differently.  If you work with FreeSWITCH and you don’t share my mental block with regard to XML, you are really going to like this book.  In terms of layout and readability, I think it’s one of the best titles I’ve seen from Packt.

One thing in particular I like about this book is that they don’t just give you the XML dialplan (although the XML is included), but the authors then explain to you how it works.  In addition, in many cases they also give you additional related information, such as tweaks you can make to the XML to perform slightly different functions or otherwise modify the behavior, and links to additional resources you made need.  So, you are not just viewing XML samples and then left on your own to puzzle out how they work!

In fact, I really only have one criticism of the book — it’s too short!  It’s only 134 pages from opening material to the index at the end.  But I’ll balance that by saying this — I’ve seen too many books that have a high page count, but a high percentage of the book is “filler”, much like the low-grade ground beef you buy at some supermarkets.  With this book, other than a few obligatory opening pages that tell you a bit about the authors and others involved with the book, it’s solid content.  No history of something or other, no long personal ramblings by the authors, etc. — just the “recipes” for doing the various things you might want to do in FreeSWITCH, and then the explanations as to how they work and other useful and relevant content.  You have to ask yourself the question, “Will this book save me time?” (almost certainly, if you are doing any of the things covered in the chapters of this book) and “How much is my time worth?”, and “Can I learn something from this book that would be useful to me?” (if you developing a project using FreeSWITCH, I can’t imagine how you wouldn’t).

My personal hope is that those who write, or who may be considering writing the next generation of GUI configuration programs for FreeSWITCH will get this book.  It basically shows you how to do everything you need to do to create a working PBX, and for those that are programmers, Chapter 4 is where the real magic is revealed.  That said, I would highly recommend this book for anyone attempting to develop a project using FreeSWITCH!

You can read a sample chapter here (PDF format).

FreeSWITCH Cookbook by Anthony Minessale, Michael S Collins, Darren Schreiber, Raymond Chandler (Amazon affiliate link)

Addendum: Just a bit more from the publisher’s site:

What you will learn from this book

  • Configure users and phones as well as connections to VoIP providers and even Google Voice
  • Control FreeSWITCH remotely with the powerful event socket interface
  • Route inbound and outbound calls
  • Handle call detail records, which includes inserting CDRs into a database
  • Enable text-to-speech conversion in your voice applications
  • Monitor calls via the FreeSWITCH Web interface

Link: Interesting security technique for Asterisk and FreePBX users (may work with other SIP-based PBX’s also)

 

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

This article was originally posted in November, 2010.

NOTE: For some reason WordPress absolutely hates it when I try to edit this post, and turns links and other things into piles of steaming poo.  If things don’t look right here please e-mail me or leave a comment and I’ll check it out.  WordPress, I KNOW how I want my articles to look, why can’t you just leave them alone?

One problem faced by some SIP-based VoIP PBX administrators is the issue of security when you have external extensions (that is, extensions located anywhere in the world that’s not a part of your local network). You want to allow those extensions (the ones you’ve authorized) to connect to your system, but you prefer to keep everyone else out, and preferably not even tip them off that there’s a PBX there. The idea is, if the bad guys that would like to break into PBX’s don’t even realize that there is a PBX at your IP address, they won’t waste any time trying to crack into your system.

There have been other suggestions for how to handle this but many of them require your users to take some additional action(s) that they would not normally have to take, and users hate having to lift a finger to do anything to enhance their security. Which brings us to a rather clever technique that doesn’t require user to do anything other than use their phones as they normally would. It might be a tiny bit of a pain to set up initially, but the results may be worth it. I would call this medium level security because if someone is sniffing your packets, this alone may not keep them out, but most of the lowlifes that try to break into PBX’s don’t actually have sufficient access to sniff your packet stream (and also, they’d have to know the exact technique you’re using to be able to crack this). So without further ado…

Secure your VoIP server with the SunshineNetworks knock

(As of October 24, 2012, the above link appears to be DEAD — see the edit at the end of this article)

Note that while the article recommends changing the SIP port to something other than 5060, their basic technique (the “knock”) should still work even if you feel you need to stay on 5060. My only fear about changing the SIP port would be the possibility of losing communications with VoIP providers and with other systems I legitimately send/receive voice traffic to/from. They’re probably going to keep using 5060 even if I don’t. EDIT: My concern here may be unfounded — note the comment below from Alex of Sunshine Networks, who said that “changing the SIP port is quite safe. Your SIP server will send this SIP port along in it’s first SIP invite registration to the VoIP provider. So unless your VoIP provider is actively blocking out anything else than port 5060, it should work fine. We use this technique with 3 different major SIP providers in Australia and never had problems. So far we haven’t seen any unintended consequences.”

I haven’t personally tested this, so if you do, please consider leaving a comment to let me know how it worked for you. The two things I wonder are, do these rules survive a reboot, and can you have more than one secret phrase that would let people in (in case you want to use a different one for each external extension)? EDIT: Those questions are also addressed in Alex’s comment below. Also, those of you running PBX in a Flash should take note of Ward Mundy’s comment about changing an entry in /etc/sysconfig/iptables in this thread. In that same thread, there appears a method to view the “knock” each extension is currently sending — just do “sip debug” from the Asterisk CLI for an hour or so (long enough for all your endpoints to register, after which you can use “sip no debug” to turn it off), then run this at the Linux command prompt (not from the CLI!):

grep "From: " /var/log/asterisk/full|cut -f1 --delimiter=; | sort -u

For each of your remote extensions, you’ll see a line that looks something like this:

From: The Knock <sip:234@nn.nn.nn.nn>

“The Knock” may or may not be enclosed in quotation marks, but it apparently doesn’t matter (you don’t include them in the iptables rules). If you haven’t used a specific “knock”, it could be the actual user’s name, if you set that up when you first set up the endpoint. Anyway, I’d suggest running this BEFORE you actually implement the iptables rules, so you know ahead of time what each endpoint is sending.

EDIT (Added January 8, 2012): I am now using a slight variation on this technique on one of the systems I administer. Without going into too many specifics, I will just note that some SIP devices and VoIP adapters actually already send a unique string that you can use as a “knock” – you do not have to configure a new one, you just need to find out what the device is already sending and use that. For example, let’s say you have an VoIP device connecting to your Asterisk server as extension 234. All you have to do is go to the Asterisk CLI (NOT the Linux command prompt) and enter this:

sip set debug peer 234

(Replace 234 with the actual extension number). Now, assuming that the device is connecting to your server, you will start to see SIP packets scroll across your screen. Within a few minutes you should see one like this (IP addresses have been xx’ed out):

<--- SIP read from UDP:xx.xx.xx.xx:5061 --->

REGISTER sip:xx.xx.xx.xx:5060 SIP/2.0
Call-ID: e10700c2@xx.xx.xx.xx
Content-Length: 0
CSeq: 56790 REGISTER
From: <sip:234@xx.xx.xx.xx>;tag=SP8f427e45f1e19cb24
Max-Forwards: 70
To: <sip:234@xx.xx.xx.xx>
Via: SIP/2.0/UDP xx.xx.xx.xx:5061;branch=z4b9hGK-4f0473a8;rport
Authorization: DIGEST algorithm=MD5,nonce=”37cd169d”,realm=”asterisk”,response=”a726bfed5db321a7bc967b997b5157c2″,uri=”sip:xx.xx.xx.xx:5060″,username=”234″
User-Agent: xxxxxx/xxxxxx-x.x.x.x
Contact: <sip:234@xx.xx.xx.xx:5061>;expires=60;+sip.instance=”<urn:uuid:nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn>”
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER
Supported: replaces

<————->

If you don’t see this you may need to increase the debug level. After you see a packet like this, you can turn off sip debugging:

sip set debug off

The string you are looking for is in the Contact: string above (the nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn is replaced by a unique string). So, where in the instructions for the “knock” they show a sample string such as:

iptables -I door 1 -p udp --dport 5060 -m string --string "mysecretpass" --algo bm -m recent --set --name portisnowopen

I would change the --dport parameter to 5060:5061 (since an VoIP adapter sometimes uses port 5061 for the second service provider — for an device that allows up to fours service providers, use 5060:5063) and the --string parameter to “<urn:uuid:nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn>”, but using the actual string sent by the device, of course. I know the Sunshine Network people recommend using something other than port 5060 but I just can’t bring myself to go quite that far, and even their examples show 5060.

Some other SIP-compliant devices also send unique strings in their REGISTER packets. One that does NOT do so, as far as I am aware, is the venerable Linksys PAP2. And I also do not believe that any of the Sipura line of devices send such a unique string.

Naturally, if an intruder KNOWS you are using that technique, they could try a brute-force attack on the unique string. So I recommend only using this with “uncommon” extension numbers (not 200 or 1000, for example) and with a VERY strong secret/password on the SIP connection. But it is another line of defense against would-be intruders!

EDIT (Added October 24, 2012): The original article, and most of the original site for that matter, seems to have gone offline. While I’m not going to repost the original article here without permission, I will give you a few more details and a couple of excerpts. First, they advised that you change the SIP port to something other than 5060 – they suggested using something in the range 20001 through 49000, though I am not sure why. They uses port 34122 in their examples, and noted that if you are running PBX software that has a “SIP Settings” module, if your find a setting for “Bind Port”, that would be the one to change. Of course if you do this, you then have to change the SIP port on ALL your SIP-based phones and VoIP adapters.

With regard to the “knock” itself, they said this:

Technical information :
… Technically, our knock consists of a secret passphrase which is sent together with the first SIP packet from the phone to the server. SIP packets are text files, very much readable like http packets are. The SIP headers in a REGISTER invite packet have a lot of information, and one of those headers is called the “Display Name”. This display name is used only internally in your Asterisk server and has no other use, so we figured we could fill in anything and the Asterisk functionality would still work fine. We decided to use it as a port knock password.

How does it work :
The Asterisk administrator sets up a simple iptables rule. The iptables rule checks for a secret phrase inside packets sent to the SIP port ( 5060 by default, 34122 after having changed it ). Unless it finds this secret phrase, it will drop the packets to this port. All the remote phone has to do is fill in the “User Name” SIP property on his SIP phone with the secret phrase, and he will be able to connect.

What you then needed to do was to go to into your Asterisk server and from a Linux command prompt, issue the following command:

iptables -N door

Then for EACH “knock” string you want to use, you would do this from the command prompt (note this is only one line, and note that 34122 is the example port and “mykn0ckstr1ng” is an example “knock”):

iptables -I door 1 -p udp –dport 34122 -m string –string “mykn0ckstr1ng” –algo bm -m recent –set –name portisnowopen

If you have anyone that needs to register with your server but cannot send the “knock”, but is at a fixed IP address, you’d add a line like this for each instance (again the port and ip address would probably need to be changed, and note that an entire subnet can be specified as in this example — just leave off the /24 if it’s a single ip address):

iptables -A INPUT -p udp –dport 34122 –source 10.10.1.0/24 -j ACCEPT

Then you would enter these three lines, but again using the correct port rather than 34122. In the first line you see the number 4000 — that is amount of time in seconds that the port will be open, and should be greater than 3600 because that’s the default registration timeout for many sip phones and VoIP adapters. The original article notes that you could use 86400, which is a full day:

iptables -A INPUT -p udp –dport 34122 -m recent –rcheck –seconds 4000 –name portisnowopen -j ACCEPT
iptables -A INPUT -p udp –dport 34122 -j door
iptables -A INPUT -p udp –dport 34122 -j DROP

And finally, to make iptables use these rules, you’d enter:

service iptables save

The original Sunshine Networks article notes that…

This code keeps port 34122 closed ( DROP ) unless someone has opened the door ( door ) in which case they are allowed to pass the door for a little more than 1 hour ( 4000 seconds ). Each time the phone re-registers , the SIP secret pass header is sent, and the door is reopened for 4000 seconds. Since the default SIP reregistration time on many phones is 3600, the 4000 seconds will make sure that as long as the phone is connected to the SIP server, or needs to be connected, the dynamic firewall rule is always active.

Once you have done this, if you configure the Display Name or User Name setting with the “knock” string, it should be able to get through your firewall. Any phone that doesn’t have this string won’t. Of course you can always make the “knock” something that a phone already sends (in a SIP register packet), as noted in the previous edit, and then you don’t have to reconfigure the phone at all. If a phone or device tries to connect without sending the “knock”, the firewall won’t allow it (assuming you haven’t previously created some other rule that allows the traffic to pass) and the connection will fail, or at least that is how it’s supposed to work (I make no guarantees because I didn’t come up with this).

If you enter the command cat /proc/net/ipt_recent/portisnowopen you will get a list of IP addresses that have successfully used the “knock” to connect. Remember that after you implement this, it can take up to an hour for a device to attempt to reconnect.

If anyone ever spots the original article back online, please let me know and I’ll remove this edit. I’d rather you get the information direct from the original source anyway, and the short excerpts I have provided here don’t give the complete overview that the original article provided.

EDIT (February 23, 2014): It appears that there is an archived copy of that original article on the Wayback Machine, although we do not know if it is the most recent edit of that article prior to the site disappearing.

Link: Using FreeSWITCH to add Google Voice to Asterisk

 

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

EDIT (2018): This article is extremely out-of-date and in no way useful today, and will probably be removed from this site at some point in the future. You might find this article more useful: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware.

For those of you using Asterisk, Bill over at the PSU VoIP blog has come up with a way to interface Asterisk with Google Voice, by co-installing FreeSWITCH (which also supports Google Voice).  Turns out that Asterisk and FreeSWITCH can co-exist on the same server, though you do have to change the configuration a bit so they don’t compete for the same ports.  Anyway, Bill has come up with a how-to on adding Google Voice integration to current versions of Asterisk, so if that interests you, head on over and have a look:

Using FreeSWITCH to add Google Voice to Asterisk

The bonus is that once you get FreeSWITCH installed you can play around with it and look at some of its other features, if you are so inclined. Of course, the Asterisk folks could backport the Google Voice support to previous versions and make it unnecessary to do things like this, but I’m not holding my breath.

EDIT (January 26, 2012): The Google Voice channel drivers in Asterisk 1.8 have become unreliable enough (in my personal opinion, anyway) that I just used the technique shown in this article, and I must say that it works a LOT better than Asterisk 1.8’s Google Voice support.  I also added some comments to that article (probably too many!) that among other things show how I got it working for multiple Google Voice accounts.  So I would now recommend using this method to bridge Asterisk to Google Voice in preference to using Asterisk 1.8’s native channel drivers (unless you are very short on memory and/or storage space) — it just works, and calls connect faster.  Read the article AND the comments under it first, so you’ll know what to expect, and do be aware that it takes a relatively LONG time to compile and install FreeSWITCH (compared to Asterisk).  At points during the installation it may look like it’s stuck in an endless loop, but it really isn’t. Just go away and take a walk outside or something, and come back in a while and it should be done.

Review of FreeSWITCH 1.0.6 by Anthony Minessale, Darren Schreiber, Michael S. Collins (Packt Publishing)

 

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

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

There are also two appendices:

  • Appendix A: The FreeSWITCH Online Community
  • Appendix B: The History of FreeSWITCH

The  Packt Publishing web site also has this to say about the book:

What you will learn from this book :

  • 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.

FreeSWITCH 1.0.6 by Anthony Minessale, Darren Schreiber, Michael S. Collins (Amazon affiliate link)

Related: Review of FreeSWITCH Cookbook by Anthony Minessale, Michael S Collins, Darren Schreiber, Raymond Chandler (Packt Publishing)