Archive for software

Link: A New Project To Run Mac OS X Binaries On Linux

This falls into the category of “I wonder why no one ever thought of this before” — it seems to me that since OS X and Linux are both based on Unix (more or less), it would be easier to make OS X software run under Linux than Windows software.

While there is the Wine project to run native Windows binaries on Linux (and other platforms), there’s a new open-source project that’s emerging for running Apple OS X binaries on Linux in a seamless manner.

It is The Darling Project that’s set out to achieve binary compatible support for Apple OS X / Darwin applications on Linux. …

More here:

A New Project To Run Mac OS X Binaries On Linux (Phoronix)

By the way, I think they need a logo.  I suggest Tux the penguin hugging a heart with an apple stem coming out of the top.  I would suggest Tux hugging an actual apple, but you-know-who would probably sue.

Comments off

Notes on using HDHomeRun recorder under Ubuntu for lowest CPU usage when recording from HDHomeRun device

This article has been moved. Please click here to read it.

Comments (10)

Having pretty much given up on FusionPBX, I turn to blue.box, and discover it also has installation issues

Here’s the thing: I will probably hate FreePBX until the day I draw my last gasp of air (unless they relent and change the two things I really hate about that software*), so I really WANT to like one of the other software PBX alternatives. But, they sure don’t make it easy. If you saw my article Oh, FusionPBX, how you vex me (especially after I added the last two or three paragraphs), you know I have given up on trying to make FusionPBX work for the time being – it’s just not quite yet ready for new users, or people like me who think that installing a piece of software should not be like going on some kind of quest where you have to find all the pieces and make them fit together (using inadequate instructions) before it will work.

So, moving along, I tried installing blue.box (the other major GUI based on FreeSWITCH) yesterday. I did that even though I already know that their software is much more confusing to me than either FreePBX or FusionPBX — nothing there seems really intuitive compared to those other products, and yet I thought that if their ISO installation actually works (which it does, for the most part), that would be a big plus, and maybe I could get a grasp of how to use blue.box if I spent a little time with it. Alas, it was not to be. I discovered that, similar to my experience with FusionPBX, if you follow their installation instructions for the blue.box ISO, you get a botched install.

There were three problems in particular I noted. I’m guessing none of these are major issues, but they sure aren’t mentioned in the installation document:

1) After following the recommendation to change the Database password to improve system security, I got this error (note the password shown is not the actual one I used; at the time I was taking screenshots in case I wanted to do a full install walkthrough, so I put the entry shown there to indicate it should be changed):

Error message: Unable to establish a connection to mysql!

2) There is a place where the instructions say, “ESL Auth – is the authentication string. The default value is ClueCon and we recommend that you change it to enhance your system security.”:

Page where you enter ESL Auth setting

BUT if you do that, then at the end of the install you’ll get this error:

Error seen after changing ESL Auth: ESL connection refused: -ERR invalid

Now, let’s say you throw caution to the wind and don’t change either of these values. The installation will then proceed, but there’s one more pitfall you may encounter. You may see an error message such as this in your browser window:

Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/bluebox/bluebox/libraries/Package/Catalog.php on line 29

Note that this error will be a bit different each time you attempt reinstallation – here are three variations I saw:

Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/bluebox/bluebox/libraries/Package/Catalog.php on line 29
Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/bluebox/bluebox/libraries/doctrine/lib/Doctrine/Query/Tokenizer.php on line 152
Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/bluebox/bluebox/libraries/doctrine/lib/Doctrine/Query.php on line 996

In any case the install gets aborted and you are left with a failed installation.

I had high hopes for at least the installation part of blue.box, since the page detailing installation from an ISO seems at first glance to be very complete, as if they really took the time to cover all the bases. But still, it seems that maybe a few things got left out of either the instructions or the installation itself. I will also note that it’s a real feat to find these instructions in the first place, since they still haven’t been linked from the main 2600hz wiki. Had not someone told me after a previous post where to find the “old” blue.box wiki, I wouldn’t have had anything to go on (and by the way, for some reason that wiki works much better in Chrome or Opera than in Firefox, at least on my system).  My guess is that there are easy fixes for these issues, but as I was going through all this I read that a new blue.box version 2.00 may be coming out in a week or so (see below), therefore I decided not to put any more effort into this until the new version appears.

* A quick note for anyone for anyone stumbling across this blog for the first time: The two things I truly loathe about FreePBX is that they changed the method of entering Outbound Route Dial Patterns and Trunk Dial Rules, going from a super-easy way to a method that is truly a royal pain in the ass, for NO good reason whatsoever, and also that they will not allow users to do certain things that are perfectly valid in Asterisk, but that for some reason aren’t allowed by FreePBX. The latter is a rather broad category that includes things like checking that only certain characters are allowed in certain fields, when in fact Asterisk allows a wider rage of options, or not allowing a problem trunk to be specified twice in the same outbound route, in case you want to automatically retry it once before giving up and failing the call. The point is that if the user knows what they are doing and why they want to do it, the software shouldn’t get in their way or act like some kind of bully that stops users from achieving their goals. Would it be so hard to include a master switch in the General Settings that effectively turns off all syntax checking and similar checks, or at least turns them into warnings that can be bypassed rather that actual restrictions that fight tooth-and-nail to stop the user from doing something that the FreePBX developers might have never considered might actually be valid when they designed the software?

Speaking of the FreePBX developers, I used to make a distinction between the “good” developers and the “bad” developers; the guys who mostly worked in the background and got things done vs. the more vocal few that are carrying FreePBX in the direction THEY want to take it, without consulting users or seeming to care one bit how much misery they have introduced into the lives of long time users. But now my attitude is, to paraphrase a 60′s saying, “If you are part of the FreePBX development team you are part of the problem.” Either you are one of the a—holes making these bad decisions, or you are going along with them, perhaps even against your better judgment (though if you are still on that team I suspect you have long since buried your own voice of conscience). All I will say is that if someone wants to be a hero, go back to maybe FreePBX 2.7, fork it there, apply any important security fixes and update it to work with the new versions of Asterisk, remove any syntax or error checking that cannot be bypassed by the user (or make it an option to turn it off), and ASK YOUR USERS WHAT THEY THINK before making any major changes in functionality. Don’t just wake up bored one morning and decide you are going to make this neat change to the software and that eventually everyone will see that it was for the best. Oh, and don’t make changes that break third-party modules if you can possibly avoid it.

I’m sure the above will fall on deaf ears because at this point it’s likely a case of I hate them (for taking a formerly great piece of software and ruining it) and they hate me (for my unrelenting criticism of their now crappy software), and each of us at times probably wishes the other would die in a fire (well, maybe nothing quite THAT bad, but I’d certainly rejoice if several of the current developers decided to quit the project and find lives outside of FreePBX). However, I know they think that because I’m one of the few people still actively complaining about the Outbound Route Dial Patterns and Trunk Dial Rules, that everyone else has learned to accept and live with the new crappy method. It’s really more that people just give up and stop complaining when they think their complaints are falling on deaf ears. The FreePBX developers have made it pretty clear that they have no intention of going back to the old, easy entry method no matter how many people they have inconvenienced, and most users have received the message and decided to just shut up about it. Well, I’d shut up about it too if I could find something else that would be an adequate substitute for FreePBX, and I could never touch FreePBX again for the rest of my life, but so far my efforts are being thwarted at the installation stage.

In concept, I really like FusionPBX, and if ever they can get their act together and produce a decent ISO that actually installs without issues I will be more than willing to give them another try, but I am not a developer nor a coder so I really can’t help them fix their issues. I do have a lot of sympathy for their situation because it appears that it is really only one guy that is doing all the coding work on FusionPBX, and just from a couple of conversations I had with him in IRC, I get the sense that on some days he’s seriously overextending himself and perhaps running on too little sleep. But he doesn’t put together the ISO, nor does it appear that he really does much with documentation. If he had as many people on his team as the FreePBX people have on theirs (and assuming they were nice folks who actually considered the impact of changes on users) I think he could have a really great piece of software that could win the support of the user community. But one guy just can’t do it all. He can’t code, AND write documentation, AND chase bugs and other issues, AND develop the ISO, AND maintain and/or moderate an online forum (one of my main criticisms is that they don’t have a forum where solutions to problems are searchable), AND… well you get the idea.

The problem I have with FusionPBX is that when you hit a roadblock the only real way to get help is in IRC, and most of the time when I have a problem there is no one around that can help, or they are too busy to help. Or, they give short, terse answers that assume a lot of knowledge on my part that I don’t possess. Questions and answers, and clarifications on those answers play out much better in forum threads, where people have time to consider their responses and type full replies, plus you get the benefit of being able to search for and reference previous threads that may touch on your problem. As it is, I always feel like I am trying the patience of the existing users with my new-user questions (particularly when they assume my experience level is much higher than it really is or that my memory is much better than it is, and therefore do things like telling me to edit a file without specifying the path, so I have to ask about that). My memory is REALLY bad – one reason I have documented certain things so extensively in this blog is that it helps ME remember how I did something, even if it was something I did only a week ago!

As for blue.box, there is this tantalizing note in their bug tracker:

Road Map: Next 30 Days (Until 12/Dec/12)
…..
blue.box : v2.00    19/Nov/12    No issues.
Massive upgrade of blue.box

But I have no idea if that date (a week from today!) is an actual firm release date, or just a goal that someone set months ago. In any case, if a massive upgrade is in the works, I only hope that it is slightly more intuitive and easy to use than the previous version, and I hope that the installation instructions will be updated and moved to the new wiki where people can find them!

There is one thing that gives me slight pause about investing time and energy into trying blue.box, and that is that I know they originally split from FreePBX (blue.box started out as FreePBX version 3) but I don’t know if the two projects are still affiliated in any way.  When I criticize FreePBX and its developers, do the blue.box developers take as criticism of their friends, or do they perhaps feel some of the same feelings that I do about the FreePBX version 2 team?  I’m not looking for an answer to that; I’m just saying that the fact that they used to have ties to FreePBX is one of the things that has caused me to shy away from blue.box just a little.  I do NOT have anything whatsoever against the blue.box developers, in fact the few times I’ve had contact with any of them, they have been extremely helpful.  So, I guess I’ll just wait and see what blue.box version 2.0 brings.

Comments (2)

Oh, FusionPBX, how you vex me

Reinstalling any piece of software is never fun, but that’s especially true when you are starting over from scratch with a piece of software that seems to take forever to install. And when you get to almost the end of the process and then f–k it up, that really doesn’t make your day.

I decided to reinstall FusionPBX because I regretted a couple of choices I had made during the initial install. I realized that I would rather use Apache than the default Nginx for serving web pages, and also that I’d prefer to use MySQL rather than SQlite for the database. It was the latter choice that got me into trouble. Near the end of the install, this screen appeared (click on it to enlarge the image):

I especially want you to note the last few lines of the above image, which tell you what to do on the second page of the web-based part of the installation, which looks like this:

Note that the two fields mentioned at the bottom of the first image are the bottom two fields on this image.  So I filled in just those two fields, but not Database Name, Database Username, or Database password, because the first screen didn’t tell me to and because I didn’t know what I was supposed to put in those fields.  I figured that if I was missing something necessary, it would tell me and return me to that page and let me enter the missing information.  Oh, how foolish of me to think that!

What actually happened was that it printed out a screen with nothing but a bunch of MySQL error messages, and if I tried to use the back button in the browser to go back and try again, it the gave me a page with nothing on it but the background (no login screen).  After a couple of hours effort, I was well and totally screwed, and basically had to go back and start from scratch, because I had no idea how to recover from this.

My biggest complaint about FusionPBX is that they assume far too much knowledge on the part of the user, and often it’s knowledge that the user would have no way to obtain.  I couldn’t find anything on their wiki about what needed to be entered on the above screen when installing FusionPBX and MySQL, nor could I find anything that worked on how to recover from a bad install (removing config.php, as suggested on one page I found, did NOT do it because apparently the MySQL part of the installation had been partially, but not completely finished).

So if you noticed that I sort of stopped posting articles about FusionPBX, it’s because I am just finding that everything I try to do is taking me far too long, and I just get tired of all the assumptions of what I should know, when the fact is that I don’t know and the documentation doesn’t tell me what I need to know.  As I write this I am tired, and not just a little ticked that this install blew up in my face, so to speak.

Of course, if anyone had this issue before and it had been documented in an online forum, I could (hopefully) find that by using a search engine and perhaps have found out what was supposed to go in these fields.  But if someone asked in IRC and it was explained to them, well, that explanation is gone forever, and at the times when I try to do things like this IRC always tends to be like a ghost town.

EDIT: I submitted an “issue” about this, and was a little perplexed by the response posted by FusionPBX author Mark J. Crane:

Certainly this can and will be improved as time permits. Priority of database support in FusionPBX is in this order PostgreSQL, SQLite, and MySQL. The order of ease if use is SQLite, PostgreSQL, MySQL. Native support in FreeSWITCH is SQLite and PostgreSQL was recently added and MySQL is unlikely to get native support in FreeSWITCH because the libraries to do it are GPL however it is still possible to use via ODBC.

As I said before this will be improved as time and resources allow.

I hate to say it but I’m starting to more and more think that this author just doesn’t get it. When you are a user and you are following an “Easy Install” script and it offers you three choices for database server, you assume all three are pretty much equally supported unless there is some statement to the contrary. Here he’s making it sound like MySQL is a low priority and not fully supported, but he’s not at all addressing the fact that the Easy Install script offers all three as choices, yet if you pick MySQL it will not work and will screw up your installation. “Time and resources” were available for someone to put it into the “Easy” install script as a choice, but not to make it actually work, and this response suggests that the author really doesn’t care all that much if you have problems. Maybe it would take a lot of time and effort to make it work, but I’ll bet it would not take a lot of time to remove the MySQL choice from the Easy Install script until it does, which is something an author might do if he were the slightest bit considerate of his users.

F—k it. I’m through with FusionPBX. It’s just not ready for “users” yet. I’m not saying it won’t work well enough for some people, especially the types that still look upon software installation as a challenge or a game, where part of the “fun” is getting it all to work. But if you’re expecting to just install and go, and have everything work as it should, you might be sadly disappointed.

Comments (6)

FusionPBX Caller ID Lookup support – what I know so far (and what I don’t).

Previous: FusionPBX Basic Configuration: Using Google Voice and Using YATE to overcome Google Voice issues in FreeSWITCH and Asterisk

One of the main reasons I have been reluctant to use FusionPBX in actual “production” use, besides the fact that I’m still in the learning process, is that there is no equivalent of the Caller ID Superfecta module for FusionPBX.  This doesn’t matter as much if you are not using Google Voice or some other service that doesn’t provide Caller ID names, but if you are then it’s nice to have a way to attempt to look up a name using one or more of the free online services.  FreeSWITCH supports this to some extent with their CID Lookup module (mod_cidlookup) but FusionPBX offers no built-in support for it, except for the following:

1) You can enable or disable the module, and stop or start it from System|Modules:

FusionPBX Module List – CID Lookup

The above shows the module enabled and running, but that’s not the default state. To enable it, click on the edit icon on that line and set the two Enabled fields to True and then Save:

FusionPBX Module Update – CID Lookup

Then you can go start the module, but it won’t do much until you configure it, and FusionPBX doesn’t have a configuration utility, which brings us to…

2) You can directly edit the cidlookup.conf.xml file used by the module from Advanced|XML Editor:

FusionPBX XML Editor showing default cidlookup.conf.xml file

As you can see in the image above, the file is in the Files|autoload_configs section of the XML editor, which translates to /usr/local/freeswitch/conf/autoload_configs in the Linux filesystem (at least that is the case if you used Debian Linux and the Easy Install script).

Documentation for the module is in two pages on the FusionPBX and FreeSWITCH wikis:

Mod cidlookup (FusionPBX wiki)
Mod cidlookup (FreeSWITCH wiki)

Where I am having difficulty at the moment is that they talk about creating a table in a database, but I’m not sure that’s even necessary for what I want to do (use one or more web sites as lookup sources), and in any case they don’t give complete instructions for doing that. It’s as though they assume you have worked with whatever database FreeSWITCH uses and know where you have to be to start creating a table, but I don’t. Also, by default, FusionPBX uses SQLite, but the example that would be relevant to my system is labelled “PostgreSQL (fusionpbx version 3 or higher)”, and that makes me wonder if the examples shown are truly relevant to my system (and if they aren’t, do I need to do a complete reinstall to use PostgreSQL, or what)?

FusionPBX doesn’t seem to yet have an equivalent of the “Asterisk Phonebook” so the idea of using a local database to store Caller ID listings as an additional lookup source makes me wonder how you would manage that (add/edit/delete individual entries — that alone cries out for a configuration page), and then there is the question of how you would actually get your Inbound Routes to USE the Caller ID Lookup.

And assuming you can make that all work, then there is the question of whether you can add additional lookup sources that can be checked, in case the first doesn’t return anything useful (again, similar to what Caller ID Superfecta does). I’m sure all of this can be done, but given my age and the increasing difficulty I am having figuring things like this out, I don’t know if I will ever be able to figure this out or not — if I do I will update this article accordingly.  EDIT: See the comments on this article for a few additional bits of information that may be helpful if you are trying to get this to work.

I want to preface this by saying that there are a lot of things I really like about FusionPBX, but this is one of those cases where the Wiki doesn’t give quite enough information to be useful to a new users, and the lack of an online Forum means you can’t ask for help in setting this up, and then leave a permanent record of any responses that others can read.  I’ve already seen some indication that people might be getting tired of answering questions in the IRC channel (or maybe someone was just having a bad day), but if the answers that are provided scroll off the screen and are gone forever, then of course new users will want to cover the same ground that’s been covered before (maybe many times) with some other user.  Either getting the Wiki in better shape, or having an online forum would help that situation.  Unfortunately, the code that approves new Wiki users (by sending an e-mail confirmation) is broken, so now even if someone wanted to help improve the Wiki, they might not be able to if they don’t already have an account that’s been approved.

Comments (35)

FusionPBX Basic Configuration: Using Google Voice

Previous article: FusionPBX Basic Configuration: Creating an Inbound Route

The intent of these articles are to show you how to do a few basic things in FusionPBX and to give you a little bit of the “flavor” of it. Both FusionPBX itself and this article are works in progress, and particularly if you are reading this within the first week or so after I post it (or even the first YEAR in this case), you might want to check back later since there is a high likelihood I will have made edits and corrections. If you haven’t yet installed FusionPBX, see Installing FusionPBX successfully — Part 1: Installing Debian Linux and Installing FusionPBX successfully — Part 2: Installing FusionPBX for information on that.

At the outset of this article, I want to say that this is the first time I have had only limited success in accomplishing something I set out to do in FusionPBX, and if you’re still reading this sentence you’ll know that I haven’t yet resolved this issue.  The main problem I encountered was that outgoing Google Voice calls take an unreasonably long time to complete.  In my tests, it was about 20-25 seconds between the time I finished dialing or entering the number to be called, and the time the called phone actually commenced ringing.  By contrast, when using an Obihai device, the delay was closer to 5-10 seconds.  Those of us who use Google Voice are used to some delay on outgoing calls, but 20-25 seconds is just too much.  This is a FreeSWITCH issue, not a FusionPBX issue, but still, until this issue is resolved it makes the use of FusionPBX for outgoing Google Voice calls a non-starter. (EDIT: It appears they tried to fix this bug, but after upgrading FreeSWITCH to get the “fix”, I found that outbound Google Voice calling was now completely broken).

For what might be a better approach to handling Google Voice calls, see Using YATE to overcome Google Voice issues in FreeSWITCH and Asterisk.  But even if you plan on going that route, if you are new to using FusionPBX you may want to read this article anyway, because it shows you how to do a few more things in FusionPBX that may prove useful in similar situations.

Just in case you can tolerate the long delay, or you want to use the Google Voice support for incoming calls only, I’ll walk you through the steps here.  From the main menu, go to accounts|XMPP Manager and then on the next page click the add icon to get to a Profile Edit page.  Fill it in as follows, substituting your Google Voice number for 8005551212 (for example, use gv followed by your ten digit Google Voice number as the Profile name), and enter the address of the Gmail account associated with your Google Voice account (which should NOT be a Gmail account that you actually use for e-mail, since it might interfere with incoming calls) in the Username field:

FusionPBX XMPP Profile Edit

I should probably note that you can use whatever you want as the Profile Name (or leave the default value) but if you plan on ever having more than one Google Voice account, then I suggest you use gv followed by your ten digit Google Voice number, so you can tell the accounts apart.  The name you use here will be important later on, so don’t use something long or fancy here.  Before saving these changes, click the Advanced button to expose more fields, and change the context to public.  This allows the use of an Inbound Route to route calls:

FusionPBX XMPP Profile Edit showing Context set to public

Now click Save.  At this point you will be returned to the FusionPBX XMPP Manager:

FusionPBX XMPP Manager

Note that if you’ve never created an XMPP profile before, there will probably be nothing shown in the Status column, and that means it isn’t working yet.  From the main menu, go to System|Modules and scroll down to the Auto section and look for the Dingaling module:

FusionPBX Module Configuration showing Dingaling disabled

Click on the edit icon next to the Dingaling line to bring up this page:

FusionPBX Dingaling module configuration

On the above page, change the settings for Enabled and Default Enabled to both be true, then click Save,  You’ll then go back to the System|Modules page:

FusionPBX Module Configuration showing Dingaling enabled but not started

Now click the Start link for Dingaling – when the page refreshes, the link should have changed to Stop, which means it’s now running:

FusionPBX Module Configuration showing Dingaling enabled and started

If you go back to the XMPP Manager, it should show that the status is now AUTHORIZED:

FusionPBX XMPP Manager showing AUTHORIZED status

Now that your Google Voice account is registered with FusionPBX, you need to make a way to handle incoming and outgoing calls. Let’s start with incoming. Go to Dialplan|Inbound Routes and click the icon to add a new Inbound Route:

FusionPBX Inbound Route for Google Voice

In the Name field, I suggest you use the same as the XMPP Profile name, in other words, gv followed by your ten digit Google Voice number.  This will help you keep multiple Google Voice accounts separate.  The Destination is your Google Voice number, and the Action is wherever you want to send the call (Extension 1000 in this case).  The Description is optional, and can be any short note that is useful to you.  Click Save, then when the page listing your Inbound Routes appears, use the edit icon to come back into the page for further editing:

FusionPBX Inbound Route for Google Voice showing Conditions and Actions

If you’ve ever set up a Google Voice account on another type of PBX, you may have run into the situation where you need to send a touch tone “1″ to Google Voice to accept the call.  FusionPBX doesn’t do that by default, but it’s easy to add.  In the Conditions and Actions section, click one of the add (+) icons to add a new action.  You should get a page like this:

FusionPBX Dialplan Detail page

Fill out the above page as shown. For clarity, the Data field contains:

execute_on_answer=send_dtmf 1

Then click Save and you should now see the added line in the Conditions and Actions:

FusionPBX Inbound Route for Google Voice showing added action

When you have done this, try placing a call to your Google Voice number – it should go to the destination you set. If you made the destination an IVR or something else that answers “immediately”, it may answer too soon for Google Voice’s liking. In that case, you can add another action to introduce a bit of delay before answer. You probably don’t need to do this if you are sending incoming calls to an extension, or some other destination that doesn’t answer immediately:

FusionPBX Dialplan Detail page — adding one second delay when answering a call

Now let’s try an Outbound Route.  For the Dialplan Expression, pick 11 digits long distance from the dropdown menu and it will fill in the regular expression. The Description is optional and can be whatever you like.  Fill in everything else as shown:

FusionPBX Outbound Route for Google Voice

Save the page, then edit it to expose the Conditions and Actions:

FusionPBX Outbound Route for Google Voice showing Conditions and Actions

When I told you above to use gv followed by your ten digit Google Voice number as the XMPP profile name, the idea was that you could have more than one Google Voice account and there would be a way to distinguish them.  But because we did that, we need to edit the last line of the Conditions and Actions (the bridge action), so click the edit icon next to that line – it should bring up this page:

FusionPBX Outbound Route for Google Voice – Dialplan Detail

Note the gtalk in the data field – that has to be changed to match the XMPP profile name.  You have a couple of options here.  You can directly insert the XMPP profile name, like so:

FusionPBX Outbound Route for Google Voice – Dialplan Detail – Data edited

But if you do that, there will be no restrictions on which extensions can use which Google Voice accounts.  A better idea, suggested by AviMarcus in the #fusionpbx IRC channel, is to use the variable ${accountcode} instead of the XMPP profile name, assuming you aren’t currently using the Account Code field in your extension settings for anything.  An advantage to this method is you can use ONE Outbound Route for all your Google Voice calls, and each call would find its way to the correct Google Voice account :

FusionPBX Outbound Route for Google Voice – Dialplan Detail – ${accountcode} variable in Data

When that’s done and you have saved the change, the Outbound Route page should look like this (if you used the first option, otherwise the final line of Conditions and Actions will show ${accountcode} instead of the XMPP profile name):

FusionPBX Outbound Route for Google Voice showing modified Conditions and Actions

This is optional, but recommended – click on one of the add icons under Conditions and Actions to add a new action, and fill it in as follows:

The reason for this is to address the issue where you do not hear any ringback tone during an outgoing call.  Just be aware that the ringback tone you will hear is totally fake, and to some degree deceiving, since you may hear three or four “rings” before the called phone ever starts ringing.

One last thing, if you used the ${accountcode} option above, go into the configuration for each of your extensions that will use a Google Voice account for outgoing calls, and insert the correct XMPP profile name of the Google Voice account in the Account Code field:

FusionPBX — Setting the Extension Account Code to match the XMPP profile name

Note that one or more extensions can use the same Google Voice account, as long as the proper Account Code (XMPP profile name) is entered for each extension).

Of course, the ${accountcode} variable is not the only one that could be used in this selection technique.  There are a few other FreeSWITCH channel variables that might be just as useful, if used as the XMPP profile name.  For example, perhaps ${caller_id_number}, ${caller_id_name}, or ${username} could be used.  The nice thing about using ${accountcode} is that it can be set in each extension independent of any other considerations, and the same Account Code can be used for as many extensions as needed.  But if you are already using the Account Code setting for some other purpose, then try an alternate FreeSWITCH channel variable and see if that will work for you.

One other option you could consider is that there is a field in the FusionPBX Extension configuration called Toll Allow. According to the FusionPBX Wiki,

Toll Allow is a variable that can be set per extension. It allows you to limit who can make what type of calls. Note that although the variable is provided in the extension configuration, the default dialplan DOES NOT make use of it. Therefore if you want to use it you need to add statements to the dialplan to enable it.

The following are notes on Toll Allow that were captured from IRC discussions on the topic. This needs to be updated by someone who understands it or has used it: …

For more information on Toll Allow, go to the FusionPBX Wiki Extensions page and scroll down to “Notes on Toll Allow”.

For more information on XMPP and Google Voice and other topic mentioned in this article, see the following FusionPBX Wiki pages:

XMPP Manager
Modules

You might also find these pages on the FreeSWITCH Wiki helpful:

Mod dingaling
Channel Variables
Google Voice

Note that on the latter page, there is a section near the bottom that talks a bit about getting Caller ID Name on incoming Google Voice calls. In FusionPBX the action specified by the line <action application=”cidlookup” data=”$1″/> would be added to the Inbound Route in the Conditions and Actions section, in the same way that we added the other actions in that section. And, CID Lookup would have to be enabled from System|Modules, Applications section. You’d also need to configure the CID Lookup module, and at the moment I don’t know how to do that.

My problem right now is the excessive delay on outgoing Google Voice calls. If I can’t find a solution to that, then FusionPBX (and, indeed, anything FreeSWITCH-related) isn’t going to be as useful to me. The funny thing is, I have an older version of FreeSWITCH with a minimal configuration set up solely for the purpose of passing Google Voice calls to and from Asterisk, running alongside Asterisk on another server, and it does NOT have this issue, so I don’t know if the problem is something that came up in a FreeSWITCH upgrade or what (although the more I read, the more I suspect that is exactly the situation). I’ve now noticed that FreeSWITCH stalls for several seconds at THREE different points while completing an outgoing Google Voice call!

I have no idea what is happening at this point but the one thing I know for sure is that I don’t have a clue how to fix this issue. And until it’s fixed, there is really no point in me going any further in this. I could probably use some type of workaround but I was really hoping all this could be run on one server.

Once again, see Using YATE to overcome Google Voice issues in FreeSWITCH and Asterisk for another approach that (for the time being) works MUCH better, especially for outgoing Google Voice calls.

Anyway, I hope you have enjoyed these articles up to this point — they’ve represented a major effort on my part over the past week or so, and I’ve lost considerable sleep while working on them, which may be why I’m just a little cranky today (that, and the fact that WordPress and Firefox don’t seem to mix well under OS X, and resulted in the accidental posting of an early version of this article that remained up for about 20 minutes while I became more and more frustrated that WordPress wouldn’t respond to my efforts to change it back to a draft. I finally wound up deleting the entire article and starting over, after of course saving a copy of what I had written thus far).

If you have any thoughts on how I can resolve the outbound call delay issue, or can add anything useful to this article, please leave a comment!

Comments (1)

FusionPBX Basic Configuration: Creating an Inbound Route

Previous article: FusionPBX Basic Configuration: Creating a Gateway to an Asterisk server and an Outbound Route

The intent of these articles are to show you how to do a few basic things in FusionPBX and to give you a little bit of the “flavor” of it. Both FusionPBX itself and this article are works in progress, and particularly if you are reading this within the first week or so after I post it (or even the first YEAR in this case), you might want to check back later since there is a high likelihood I will have made edits and corrections. If you haven’t yet installed FusionPBX, see Installing FusionPBX successfully — Part 1: Installing Debian Linux and Installing FusionPBX successfully — Part 2: Installing FusionPBX for information on that.

Assuming that you have by now created a Gateway to another server, you still need some way to direct incoming calls, and that is where Inbound Routes come in. To create a new Inbound Route, from the main menu go to Dialplan|inbound Routes, and the page that will list Inbound Routes (once you have created one or more) will appear. Click the icon on the right hand side of the page to add a new Inbound Route, and this page should appear:

FusionPBX Inbound Call Routing – Add Route

Some of the main Actions available include Call Center, Call Group, Conferences, Destinations, Extensions, FAX, FIFO, Gateways, Hunt Groups, IVR Menu, Language, Recordings, Ring Groups, Time Conditions, Voicemail, and Other. Many of the actions have sub-items, for example, under Extensions or Voicemail you see a list of your extensions, and can route calls to the extension directly or to its voicemail, or you could send them to a Ring Group that encompasses multiple extensions. The “Other” category will be interesting to the technically proficient; in a basic installation its sub-items include answer, bridge, db, export, global_set, group, hangup, info, javascript, lua, perl, relect, set, sleep, transfer, and other (the latter just lets you enter your own Action Application). I suppose that perhaps this menu could get expanded further if you add or enable other modules.

Typically you might enter a route name in the Route field, a DID number in the Destination Number field, a destination such as a particular extension, voicemail box, Ring Group, IVR, etc., and optionally a Description of the route.  The Order is only important if you have more than one inbound route that could act on the same incoming call, and in that case you may want to change it to give certain routes higher precedence.  As will be explained later, you are not limited to using a destination number as the criteria for routing an inbound call, so it is possible that an incoming call could be processed through any of two or more inbound routes, and in that case you’ll probably want to define the order in which these routes are processed.

If, under the Action dropdown, you select an extension, it will actually be converted to string consisting of the string “transfer:” followed by the extension number, followed by the string ” XML default”, so if you selected extension 1000 as the extension, what would actually be placed in that field is transfer:1000 XML default.

After you have created an Inbound Route it’s possible to go back into it and edit the contents of certain fields.  Why would you want to do that?  Well, consider that in the previous article, I set up a Gateway to an Asterisk server, and one thing I wanted was for users on that server to be able to dial an extension number and reach users on the FusionPBX server.  It’s easy enough to pass the calls from Asterisk to FusionPBX, but without an Inbound Route, FusionPBX won’t know what to do with them.  While, in theory, I could set up a separate Inbound Route for each extension, it would be much easier to have one Inbound Route to handle calls to all extensions, and it turns out that is possible.  However, there’s a small issue on the way to making that happen.

Let’s say that I tried to set up an Inbound Route that would handle only extension 9999 (I would not really give an extension the number 9999, but that’s not what I really want to do anyway, so it doesn’t matter at this point).  You would think that I could set up an incoming route for a single extension, like this:

FusionPBX Inbound Call Routing – Attempt to add 4 digit extension

The problem is that at some point in the past, some code was inserted that won’t let that happen.  The reasons for it may not be valid any longer, but it still exists, and therefore when you click the Save button you get this error message:

FusionPBX Inbound Call Routing – Error message

I am told that this is something that will be fixed in the next release, because there is now no good reason for restricting an incoming number to 5 or more digits (also this error message lies – an attempt to use a five digit number gets the same error.  You have to use a six digit or longer number to avoid the error).  Now, those of you who have read my rants about “The Software I Have Come To Hate” know that one of my pet peeves is its syntax checking, and the fact that it won’t let you do things that are perfectly valid as far as the underlying PBX software is concerned.  The difference is that the other software attempts to actively thwart you in any attempt you might make to bypass its syntax checking (unless you bypass that software altogether and write custom dialplan), whereas in FusionPBX a message like this is only a minor inconvenience.

So let’s try that again, this time using a six digit number to get past the error message:

FusionPBX Inbound Call Routing – Add Route using 6 digit number

After clicking “Save”, it shows up in the list of Inbound Routes:

FusionPBX Inbound Route List showing 6 digit inbound route

FusionPBX Inbound Call Routing – Inbound Routes List

Of course, this is not what was actually desired, for three reasons. First, the destination that was picked wasn’t actually a valid one — “transfer” is specified as the Action, but it doesn’t specify where the calls should be transferred.   Second, the number of digits is wrong (6 vs. the desired 4) and third, the route should accept a range of incoming numbers (any four digit number, not just 9999) and send those calls to the correct extensions. Fortunately, all this is actually possible!

Clicking on the icon to edit the Inbound Route that was just created will bring up a page that is labeled Dialplan for some reason (why is it not called Edit Inbound Call Routing, just for the sake of consistency?):

FusionPBX Inbound Call Routing – Edit Route

Note the Conditions and Actions lines at the bottom of the page. They correspond to individual lines in the relevant FreeSWITCH configuration file, and note that each one can be edited individually by clicking on the edit icon next to the line!  In this case, both the second and third lines are wrong, so those two lines both need to be edited.  For example, the second line (the destination_number) can be edited as follows:

FusionPBX Inbound Route Dialplan Detail Edit screen

Here a digit “6” in the Data line regular expression has been changed to “4“, making the new string ^(\d{4})$ to allow four digit numbers, thereby vanquishing the syntax checking error (for those that may not be regular expression experts, everything between the parenthesis is evaluated and captured, and placed in a variable called $1, which is used in the next rule).  Clicking the Save button brings back the Dialplan screen, and then clicking the edit icon next to the third line (transfer) brings up this page, which is edited as shown:

FusionPBX Inbound Route Dialplan Detail Edit screen (second edit)

What got changed here was the Data line, to $1 XML default.  By using the $1 variable, which was set by the regular expression in the previous rule, it allows any incoming number from 0000 through 9999 to be sent to a corresponding extension number, if one exists.  And how did I know to do that, you might ask?  Well, I didn’t.  I got a little help from mcrane (the FusionPBX author) in the #fusionpbx IRC channel.  Making both these changes allows direct incoming calls to four-digit extensions from another server on the same network.  After clicking Save, the Dialplan page reappears, where a couple more changes are made:

FusionPBX Inbound Call Routing – Edit Route (4 digit extensions)

In the above, the Name has been changed to 4-digits, the Number to 9999 (I don’t think what’s in those fields really matters once the Conditions and Actions have been changed, but I could be wrong, and it’s good to have something relevant in the Name and Number fields), Continue has been set to false, and a Description has been added.  After making these changes and clicking Save, this page reappears, showing that the Inbound Route has been entered correctly:

FusionPBX Inbound Call Routing – Inbound Routes List after edits

I think the above illustrates two important points. First of all, in FusionPBX, you are not hamstrung by the author’s ideas about what you should or should not be able to enter. If you know what you are doing, it’s easy to get around any syntax checking issues. And second, you probably won’t need to resort to something akin to writing a custom context in an Asterisk-based installation just to get around one small bit of dialplan that’s not doing what you need it to do. I’m sure there may be situations where it’s not this simple, but if you feel like your current software sometimes treats you like an idiot and insists on holding your hand (and occasionally slapping it) even when you know what you’re doing, then maybe you should check out FusionPBX.

Now, if you are used to using certain other software, you may notice that there’s no field for a Caller ID number, so you might think that you can’t route calls according to the Caller ID number, but that would not be correct.  Let’s take a look at how that might be done.  From the page that lists the Inbound Routes (the page shown in the image just above), click the icon with the + on it to add a new Inbound Route.  When that screen comes up, you could start by filling it in as shown here:

FusionPBX – Creating an Inbound Route that uses the Caller ID number

This assumes that 5551212 is the CallerID Number we want to trigger on, and that we selected Extension 1000 as the destination from the dropdown in the Action field.  If we just saved it this way and didn’t do anything else, it would be wanting to trigger on calls with a DID of 5551212, which is not what we want in this case.  So we would click the Save button and then when the page that lists the Inbound Routes comes up, we’d find the newly-created Inbound Route and click the edit button next to it, which would show this page:

FusionPBX – Editing an Inbound Route that uses the Caller ID number

Under “Conditions and Actions”, you can see that the second line shows the correct number, but not the correct type – the destination number (DID) is not the desired criteria to use as a condition in this situation.  Clicking on the edit button next to that line brings up this page:

FusionPBX – Editing an Inbound Route that uses the Caller ID number – changing Dialplan Detail

As you can see, clicking on the “Type” dropdown on this page reveals that it’s not only possible to use the CallerID number as a way to determine where to send a call, but there are many other choices as well!  Do you suppose that being able to route by CallerID Name might be useful sometimes?  Or that maybe there might be a need to examine a field in the SIP INVITE packet for routing purposes?

One other thing I’ll mention about the above page — in the Data field (which is obscured by the dropdown menu in the above screenshot), the pattern shown is ^5551212$ BUT this could be changed to any regular expression.  So, you could trigger on the CallerID number and then look for a pattern of invalid numbers (for example, numbers with “area codes” that begin with 0 or 1), and send such numbers to hangup or some other “black hole” destination on your system. Anyway, after changing the Type and saving the change, we wind up back at the “Dialplan” screen:

FusionPBX – Inbound Route that uses the Caller ID number now works as intended

And now the Conditions and Actions section shows the correct Type on the second line.  I will also point out that at the right hand side of that section, there is an Add button, which means you could add additional conditions.

While this may not be exactly what you are used to, it may well offer more flexibility than the software you are using now.  The ability to trigger on Caller ID name is a feature I’ve wanted for dealing with certain annoying “spam” callers that seem to have a multitude of phone numbers, but that are “nice” enough to always use the same Caller ID name.

For more information on Inbound Routes, see the following FusionPBX Wiki pages:

Inbound Routes
Getting Started

If you can add to our knowledge about Inbound Routes in FusionPBX, or can help clarify anything in this article, the comment section is open.

Next article: FusionPBX Basic Configuration: Using Google Voice

Comments (1)

FusionPBX Basic Configuration: Creating a Gateway to an Asterisk server and an Outbound Route

Previous article: FusionPBX Basic Configuration: Introduction and Creating an Extension

The intent of these articles are to show you how to do a few basic things in FusionPBX and to give you a little bit of the “flavor” of it. Both FusionPBX itself and this article are works in progress, and particularly if you are reading this within the first week or so after I post it (or even the first YEAR in this case), you might want to check back later since there is a high likelihood I will have made edits and corrections. If you haven’t yet installed FusionPBX, see Installing FusionPBX successfully — Part 1: Installing Debian Linux and Installing FusionPBX successfully — Part 2: Installing FusionPBX for information on that.

The first thing I want to show how to do in this article is create a gateway to an Asterisk server in FusionPBX.  A “gateway” in FusionPBX is the equivalent of a “trunk” in Asterisk (it’s called a Gateway in the FreeSWITCH .xml file, and FusionPBX tends to follow FreeSWITCH naming conventions), and I’ll be showing how to pass traffic between a FusionPBX gateway and an Asterisk trunk. The reason I am starting here, rather than with a commercial VoIP provider, is because many of you who will be setting up one of these systems will be in the same position I am, where you already have a functional Asterisk box and you just want to dip your toe in the water by passing traffic between the boxes.  At some point I may attempt to connect to a commercial provider, but even if I did, it probably wouldn’t be the same one you use.

However, I will note here that the FreeSWITCH Wiki has a page of SIP Provider Examples that might be useful if you are trying to connect to a commercial provider.  Note, however, that such examples might not be directly applicable to FusionPBX without a bit of tweaking, and also some of them may be out of date.  Keep in mind that I’m just starting out with FusionPBX, so I’m taking one thing at a time.

To start with, go to Accounts|Gateways from the main menu, and on the next page click on the Add icon.  It will bring up a window similar to this:

FusionPBX Gateway Edit page

Note that I am not registering with the Asterisk server because there is no need to do so in this case. As much as some of you may think I am an expert in this stuff, I’m not, and it mystifies me why sometimes registration is required and sometimes it isn’t, but in this case it isn’t. Also, when I took the above screenshot I neglected to fill in a Gateway Description, but if you plan to have more than one or two gateways you will probably want to make sure you put something in that field to help you pick the correct one from the list of gateways that you see when accessing Accounts|Gateways.

Note that what you pick as a username here will be used as the trunk name on the Asterisk server, so keep that in mind when choosing a username.  Conversely, I made the Gateway name the same as the username on the Asterisk trunk.  I don’t know if that’s required in FusionPBX or not, but it help keep things simple in any case.  The password here will match the secret in the Asterisk trunk configuration.

Now let’s look at the Asterisk side of things.  Using “The Software I Have Come To Hate” (and one of the motivations for me taking another look at FusionPBX), I set up a new trunk and gave it the trunk name newfusion (which needs to be put in both “Trunk Name” fields).  The ONLY other thing I filled in was the PEER details, which look like this.  I am not saying these settings are 100 percent correct or that all are necessary, but they worked for me:

defaultuser=asteriskbox
type=friend
secret=sameasfusionpbxpassword
host=192.168.0.123
context=from-internal
qualify=yes
disallow=all
allow=ulaw
trustrpid=yes
sendrpid=yes
permit=192.168.0.123/255.255.255.255
deny=0.0.0.0/0.0.0.0

Just so you know, I gave munged the network addresses in these examples, so even though they appear to be on the same network, in reality they were on two different networks.  The main things to keep in mind are:

The host address and the first part of the permit address must be the same.  The permit and deny fields are a security measure that can be used as long as the FusionPBX server is on a static IP address.  I only allow ulaw connections between the servers but obviously you can allow other codecs if you like.  I set the context to from-internal because I wanted the two servers to be able to pass calls between extensions as if they were on the same server, but if the connection is from an “outside” server that’s not part of your organization then you should use from-trunk instead, particularly if you have any concerns about the other server attempting to pass unwanted traffic through your Asterisk server (remember, using “from-internal” basically grants all the calling privileges that a user on the Asterisk server would have).

A note about the trustrpid=yes and sendrpid=yes lines.   FreeSWITCH sends SIP INVITE packets using a slightly different format than Asterisk expects, and therefore, whenever you get an incoming call, Asterisk will use the trunk NAME (actually the Username from the FusionPBX gateway) as the CallerID NUMBER.  So you might get incoming calls with a Caller ID Name that is correct, but with the trunk name where the calling number should be.  This is obviously not desirable, and adding the trustrpid=yes and sendrpid=yes fixes that issue, but begs the question of what happens if you only have control of the FusionPBX side and not the Asterisk side? At this point, I don’t know the answer to that, but if someone can give me a definitive answer, I will add it here. I spent a considerable amount of time on the #fusionpbx IRC channel with the FusionPBX author (mcrane) trying to figure this out, and although he and I tried several things to overcome this apparent incompatibility, so far this was the best solution I could come up with.

For those of you that may want or need to pursue this further, here are some links from the FreeSWITCH Wiki. Keep in mind that a better solution may have been staring us in the face, but at 1 A.M. the mind tends to get hazy, so don’t assume that I have already tried everything possible. However, I DID try setting the “Caller ID in from” value to “True” (you need to click the “Advanced” button on the FusionPBX Gateway edit page to see that setting), as suggested on some of these pages and in various other places, and that did not seem to help:

Connecting FreeSWITCH and Asterisk using SIP
Variable sip cid type
Clarification:gateways

That last link might be useful in any case if you are having issues setting up a gateway.  Again, if you find a better solution that can be implemented entirely in FusionPBX and does not require adding the trustrpid and sendrpid lines on the Asterisk side, please leave a comment!

Now, if you have gotten this far, you will discover that although you can make calls from FreeSWITCH to the Asterisk box (once you create an Outbound Route, which will be covered below, you won’t be able to receive calls from the Asterisk server, even if you go ahead and create an Inbound Route (the subject of the next article). The reason is that by default, FreeSWITCH wants to talk to external servers on port 5080, and Asterisk wants to talk on port 5060, though you could force it to use port 5080 by adding a port=5080 statement to the trunk configuration. There may be some advantages to using port 5080, in that it’s not a port that most hackers would expect you to be using for sip, and it’s not a port that a repressive government or ISP would be as likely to block or degrade. Bust since most Asterisk servers and most VoIP providers expect you to be on port 5060, you probably want to know how to make FreeSWITCH communicate on that port.

The FusionPBX author explained to me in IRC (edited for clarity):

FreeSWITCH works a little differently than Asterisk. 5080 is the external sip profile that doesn’t require registration. If using port 5080 is not an option, you can set an ACL entry to allow the Asterisk server (or carrier if applicable) to use port 5060.

The ACL entry is set in Advanced|XML editor:

FusionPBX Advanced menu – XML editor

Expand the autoload_configs folder, and edit acl.conf.xml:

FusionPBX – Adding a permission to the Access Control List

Add the line highlighted in blue at the place shown above. replacing 192.168.0.234 with the actual IP address of the Asterisk server, or server that you want to allow.  The line in text form (so you can cut and paste it) is:

<node type=”allow” cidr=”192.168.0.234/32″/>

It goes in the section “<list name=”domains” default=”deny”>, just before the final </list> tag.

Be sure to click the Save button at the top of the frame (small blue floppy disk icon ).

Then go to Status| SIP Status and click on the Reload ACL button:

Location of the FusionPBX Reload ACL button

The FusionPBX author also noted that it’s also possible to add a “dummy” extension that’s not actually used, and click the Advanced button to expose the CIDR field, and set that to 0.0.0.0/32 with 0.0.0.0 replaced by the IP address of the remote server, and also set the User Context to public.  This is just another way of authorizing the IP address of a remote server so it doesn’t have to register — it’s an alternative method to adding a line to acl.conf.xml, but this method allows you control of the context, although most of the time you would want to set it to public.  You wouldn’t use that extension to register to it and you wouldn’t be sending calls to it; it is more of a dummy extension that authorizes the IP/IP range, and that IP inherits things from that extension such as the context.  Port 5060 requires registration of an extension normally, but here you are just authorizing an IP address with the CIDR on the extension, creating an IP address or range of IP addresses that don’t have to authenticate and that inherit variables and parameters of the extension.  If that confuses you, just stick to the first method as explained in the previous paragraphs.

One thing that the FusionPBX author advises against — apparently some people come to FreeSWITCH and see the internal profile requiring registration on 5060, so their solution has been to change the internal profile to 5080 and external profile to 5060.  He believes this approach is a mistake, and has fixed several systems were the previous admin used that approach.  He considers that approach bad practice, because then all your phones have to register on port 5080, which is inconvenient, but also the approach can cause other issues that make life harder and more confusing.  And, it’s really stupid when all you need to do is just create a simple one line ACL entry in acl.conf.xml.

In order to test the connection to the Asterisk server, you can quickly create an Outbound Route. Many outbound routes are predefined. For example, if you wanted to create a route for outgoing Toll Free numbers in the U.S. or Canada, you could go to Dialplan|Outbound Routes, and on the next screen click the icon to add a route. You might then set up a route that looks like this:

FusionPBX Outbound Routes page

All you really need to do to create the first Outbound Route is to use the Gateway dropdown to pick the correct gateway (in this case we are sending the calls to the Asterisk server, but you could create a new gateway that sends toll-free calls direct to a provider that will accept them), and then use the dropdown in the Dialplan Expression section to pick the toll free option. Optionally, you can enter a description of the route at the bottom of the page. Then click Save, and that’s all there is to it!

Note that if you want to place calls to extensions on the Asterisk server, you could do the same thing, but select one of the other options from the dropdown, such as 3, 4, or 5 digits. But also note that you can modify the regular expression to suit your needs. For example, let’s say you want to send 4 digit extension numbers, but all the extensions on the Asterisk box start with the digits 11, while the extensions on your FusionPBX box will start with 10. In order to avoid confusion, you could pick 2 digits from the dropdown, which would give you this pattern:

^(\d{2})$

Then simply add the “11″ digits in the appropriate place:

^(11\d{2})$

And then save the modified pattern.

In case you are not that familiar with regular expressions, here is a page from the FreeSWITCH Wiki that might be of some assistance:

Regular Expression

Another great site for learning about Regular Expressions is Regular-Expressions.info, where they have a tutorial and a number of other resources.

If you make any discoveries with regard to creating Gateways or Outbound Routes in FusionPBX, or can help clarify anything in this article, PLEASE leave a comment.  Again, remember that I’m very inexperienced with FusionPBX as I write this, so there may well be better ways to do certain things!

Next article: FusionPBX Basic Configuration: Creating an Inbound Route

Comments off

FusionPBX Basic Configuration: Introduction and Creating an Extension

The intent of this article is to show you how to do a few basic things in FusionPBX and to give you a little bit of the “flavor” of it. Both FusionPBX itself and this article are works in progress, and particularly if you are reading this within the first week or so after I post it (or even the first YEAR in this case), you might want to check back later since there is a high likelihood I will have made edits and corrections. If you haven’t yet installed FusionPBX, see Installing FusionPBX successfully — Part 1: Installing Debian Linux and Installing FusionPBX successfully — Part 2: Installing FusionPBX for information on that.

The main menus

The first thing you should do have you have installed and logged into the FusionPBX GUI is to get a feel of the main menu, which consists of a top menu bar with six items. As you mouse over each of those items, a dropdown menu appears, giving you more choices. So, for example, here is how you would get to the menu that allows you to add or edit an extension:

FusionPBX Menu – Accounts – Extensions

If you wanted to create an Outbound Route, you’d go here:

FusionPBX Menu – Dialplan – Outbound Routes

And if you wanted to check the status of your SIP extensions and gateways:

FusionPBX Menu – Status – SIP Status

I mention this at the beginning so that if I tell you to go to Accounts | Extensions (as an example), you will understand that it simply means you should mouse over Accounts in the top menu bar and click on Extensions as the option. Note that the top menu items are themselves clickable, although that’s not immediately obvious.

Also, in many cases, when you click on a menu item, you will see a page that will list all your extensions, routes, etc. There won’t be any listed when you first go there, but you will see one or more icons in such lists, on the right hand side of the page, that look like these:

    Click this icon to add an item, such as an extension or route. If you are creating the first such item, this will probably be the only icon available.

    Click this icon to edit an existing item.

    Click this icon to delete an existing item. BE CAREFUL you don’t click this accidentally, because (at least in the case of extensions) there is no confirmation dialog to make sure that you really intended to delete that item.  Given the small size of the icon and the proximity to the edit icon, it would be nice if you got the chance to confirm that you really meant to delete something.

Creating an Extension:

Go to Accounts | Extensions and this menu should appear:

FusionPBX Extensions List with no extensions

Click on the “add” icon and you should see a page like this, which I have filled in with some values for a test extension:

Adding a new extension in FusionPBX

This might be a good time to remind you that you can click on any image in this blog to enlarge it, assuming it’s larger than the allotted column width for the blog.

The only thing absolutely necessary, at least in many cases, is an extension number, but you probably will at least want to fill in the caller ID information. I didn’t have a DID for this test extension so I just used the extension number as the external caller ID number. Note that you could create a range of extensions at once by using the Range dropdown. If you are observant, you may note that there’s no password field. But if you go ahead and save the filled-in page, you will come back to the extensions list, which should now show the extension you just added:

FusionPBX Extensions List with one extension added

And if you click the Edit button, you will see that now the password fields for extension and voicemail have appeared:

Editing an extension in FusionPBX

You might wonder why they do it that way, but it is because when FusionPBX creates an extension, it also creates a fairly secure password consisting of letters, numbers, and punctuation, which you can expose if you position the mouse cursor anywhere in the Password field and click (this also works for the Voicemail Password, although a secure password is not automatically generated for that):

Positioning the cursor in the Password field and clicking reveals the password

If you are happy with the generated password, simply use it with your SIP client. If not, you are free to fill in your own.

The FusionPBX Wiki notes that once you have your phone or device configured, you can test it by dialing *9664 which is a code for music on hold.

By the way, voicemail should work “out of the box” but if you want to enable the option of e-mailing voicemails, you will need to configure an e-mail server.  To do that, go to Advanced|Default Settings, where you will see a screen like this:

FusionPBX Default Settings page

I would suggest checking and (if necessary) modifying the Time Zone setting, and the fixing the e-mail settings. If you don’t have a local mail server that will accept SMTP connections (you didn’t elect to install a mail server when installing the operating system), then you can use any Gmail account (even one associated with a Google Voice account, since you shouldn’t be receiving mail on the account):

FusionPBX Default Settings showing example settings for Gmail account

The settings shown above should work for Gmail. With Gmail, it doesn’t seem to matter what you put in the smtp_from field as long as you put something there (someone could see it if they view all the headers in an e-mail, but almost all e-mail programs hide the majority of e-mail headers by default).  The smtp_username must be the full e-mail address of the account.  Note that if you have a version of FusionPBX prior to Revision 3046, the password is displayed in plain text here, so don’t use an e-mail account that you also use for super sensitive information. This is fixed as of Revision 3046, which displays ******** instead of the password.

If you did elect to install an email server (and you configured it using sudo dpkg-reconfigure exim4-config or otherwise did whatever was necessary) then you can leave the smtp_auth, smtp_password, and smtp_username fields blank (I’d also set smtp_password to disabled — it’s probably optional whether you want to set the other unused fields as disabled), set smtp_host to “localhost” and set smtp_secure to “none“. But do put something reasonable in the smtp_from and smtp_from_name fields.

You might wonder where you can access extension features such as Call Forward, Follow Me, or Do Not Disturb.  Those are accessible if you click on System in the top menu bar.  Do not select an item from the dropdown, just click on “System” and a page like this should appear:

FusionPBX — clicking System in main menu exposes Call Forward, Follow Me, Do Not Disturb options

If you then click any of the links in the “Tools” column, you’ll get a page like this:

FusionPBX page to set or modify extension features

If create a user account for your each of your users in Accounts|User Manager, and then use the “User List” dropdown on the extension configuration page to add those users to their designated extension(s), they should be able to log in and change the above settings themselves, without bothering you to do it for them. This is entirely optional; you don’t have to use the “User List” dropdown if you don’t want to.

A couple more notes about extensions:  Unless you have some valid need for it, for the moment you may want to avoid using the “Account Code” field for anything.  Later on, I will show how that field can be used to facilitate outbound call routing.  There are other ways to accomplish the same thing, so if you really need the Account Code field, go ahead and use it, but if you don’t, avoid it for now. Also, if you have a situation where when a remote extension (one not on your local network) places a call to another extension, and then hangs up but the called extension doesn’t stop ringing right away, that can sometimes be fixed by clicking on the Advanced button and the using the dropdown in the SIP Force Contact field to make a selection. Try any of the choices shown (start with “Rewrite Contact IP and port 2.0“); perhaps one of them will help. Don’t forget to save your changes!

For more information on creating extensions in FusionPBX, see:

Extensions (FusionPBX Wiki)
Getting Started (FusionPBX Wiki)

If you have any hints, tips, or discoveries to add, please feel free to leave a comment, or e-mail me at the address in the right-hand column near the bottom of this page.

Next article: FusionPBX Basic Configuration: Creating a Gateway to an Asterisk server and an Outbound Route

Comments off

Installing FusionPBX successfully — Part 2: Installing FusionPBX

Continued from Installing FusionPBX successfully — Part 1: Installing Debian Linux

I apologize that these are so hard to read unless you click on them, but I’ll try to put the pertinent points in text.

This is the login screen you get once the Debian installation is complete and the system reboots:

To get the FusionPBX install started, enter

sudo apt-get install subversion

Since this is the first time you are using sudo, you’ll be asked to enter your password:

When that operation finishes, enter

sudo svn checkout https://fusionpbx.googlecode.com/svn/trunk/scripts/install/ubuntu/ /usr/src/install_fusionpbx

sudo chmod 755 /usr/src/install_fusionpbx/install_fusionpbx.sh

sudo ln -s /usr/src/install_fusionpbx/install_fusionpbx.sh /usr/local/bin/

sudo /usr/local/bin/install_fusionpbx.sh install-both user |tee /tmp/install_fusion.log

IMPORTANT: Instead of that last line, if you want to have fewer pauses in the script than the number shown below, you might want to try this instead, but if you use this option, you need to manually change the variables in the script (use sudo nano /usr/local/bin/install_fusionpbx.sh and look at the top of the file; the variables to be edited are quite obvious.  For the database I strongly suggest that you select SQlite, which is the default, unless you want a botched installation — see my comments below).  You might also add more modules (if you need/want them) in the defines section. See the comment by soapee01 in the comments section:

sudo /usr/local/bin/install_fusionpbx.sh install-both auto |tee /tmp/install_fusion.log

I’m told that by using “auto” instead of “user“, the script will have fewer pauses where you are asked to press “ENTER”, but you do have to manually edit the script first. I didn’t know that at the time, so I went with the first option:

When you get to this point, you might question whether you are running the wrong script. You aren’t; there’s only one script for both Ubuntu and Debian, so answer y:

If you are doing a brand new install as we are doing here, then you just downloaded the latest install script, so answer y when asked if you want to continue. Otherwise the script will abort and you will just need to start over:

This is the first of several places where the script will stop and ask you to press ENTER. Presumably you won’t see most such screens if you run the script in auto mode:

This is the part that got me. “Press ENTER to continue (check for errors)” — you see this a lot, and honestly I probably wouldn’t know an error unless it printed blinking red text saying “THIS IS AN ERROR”.

“Press ENTER to continue (check for errors)” again…

And again…

And again…

And again…

And again…

And again, after some attempt to display something unreadable in large ASCII art…

And again…

And again (by about this point you start to wonder if it will ever end)…

And again…

And again (just shoot me now)…

FINALLY, an actual question, asking if you prefer Apache or Ngnix.  When I did this, I couldn’t care less, and Ngnix is the default, so I accepted that. But now I realize that this may have been the wrong choice, if only because you can’t use .htaccess files to secure Ngnix.  If I ever do this again, I’ll choose Apache:

Oh no, we are back to this again…

Aaaaaaarrrrrrrggggggghhhhhhh…….

Can I get a robot that will just press ENTER for me?

And finally another actual question, asking whether you want to use MySQL, PostgreSQL, or SQlite. Since SQlite is already installed and required, why would I want a second database? Well, I might if I were running a system with a higher number of users or phones (see soapee01′s comment in the comments section), or if I plan on adding any software that depends on MySQL.  The default is to use SQlite, so I accepted it, but there have been a couple of times when I wished I had chosen MySQL.  Then again, when I tried doing a reinstall and choosing MySQL, it turned into a disaster that basically meant I had wasted a couple hours of my life (see Oh, FusionPBX, how you vex me for the details, but I’ll warn you ahead of time that I was not in particularly good humor when I wrote that).  If you don’t need anything more than SQlite, pick that, but if you do need something more than SQlite then I would personally avoid FusionPBX until they can get their documentation and the instructions given in the install script to match reality, unless you don’t mind the frustration of doing the installation process multiple times until you get it right.

Finally you get to the point where you need to go to the web-based GUI and enter some information. It will display this message, and wait for you to use the browser to complete the installation:

When you get to this screen on your browser, the Username and Password are probably the only things you need to fill in (and maybe change the Database Type if you selected something other than SQlite). BE CAREFUL when you fill these in – if you make a typo and don’t notice it, you will not be able to access the GUI and will probably need to restart the installation from scratch! So take a careful look at what you have entered, and make use that you actually typed what you think you’ve typed before clicking on “Next”:

On this screen, you will most likely only want to click “Next”, which completes the installation:

The install is finished, and you are returned to a command prompt:

The browser will go to a login screen:

And that completes the FusionPBX installation. It’s not difficult, but there is sometimes a considerable amount of time between the prompts to press ENTER, so most people would tend to wander off and do something more interesting, only to come back later and find it sitting on the next prompt to press ENTER. In my opinion, the Wiki page containing the instructions should advise inexperienced users to run the script in auto mode rather than user mode. I was going to go in and add something to that effect, but something is broken in the registration process and I could not complete a registration for the Wiki. I’m told the Wiki was recently moved to a new server, and apparently the configuration got messed up a bit.

After completing the installation this way, FusionPBX actually seems to run without errors. Configuration via the web-based GUI doesn’t appear to be difficult, although there are a couple of “gotchas” if you are attempting to connect to an Asterisk server (it works, but the configuration involves a couple of non-obvious things that are probably just differences between FreeSWITCH and Asterisk). Since I am just getting started with this and only working on it in my spare time, I’ll try to cover those in my next article.

By the way, if you ever want to upgrade FusionPBX to the latest version and you have installed it essentially the same way I did, there are a couple ways to do it. Probably the easiest way is to go to the Linux command prompt and issue these commands:

cd /var/www/fusionpbx
sudo svn update

It should show you a list of added and updated files, followed by “Updated to revision nnnn.” (where nnnn is the revision number).

The other option is to run this command:

sudo /usr/local/bin/install_fusionpbx.sh upgrade-fusionpbx auto

If you ever want to upgrade FreeSWITCH, you can do this, BUT AT YOUR OWN RISK. I temporarily broke a working system doing this, so if you don’t have the skills to troubleshoot a broken installation then don’t do this, at least not without making a full system backup first. That said, if things don’t work immediately after the upgrade (or even after a system reboot, for that matter), don’t immediately panic – it seems that it may take a few minutes for everything to start working again.

sudo /usr/local/bin/install_fusionpbx.sh upgrade-freeswitch auto
sudo /usr/local/bin/install_fusionpbx.sh fix-permissions auto
sudo service freeswitch restart

Note that the use of “auto” at the end of the above lines will skip many of the pauses and prompts to press ENTER.  If you really want those, substitute “user” for “auto“.

A word about firewalls:

The Easy Install script did not appear to install a firewall, though in theory it probably should have. It does install Fail2Ban, but if there’s no firewall that doesn’t help much. To see if the firewall is running, enter

ufw status

from the Debian or Ubuntu Linux command prompt. If it shows you a list of firewall rules, then it is installed. But if you get a “command not found” message, then you will need to install it using:

apt-get install ufw

Then you need to add the firewall rules. Go to the Ubuntu Firewall page on the FusionPBX wiki and enter the lines in both text boxes, in the order shown, except for the last one (don’t enter the ufw delete 3 line).

If you know what you are doing you can modify those rules as necessary. In my experience, after making any changes to the firewall you may need to restart Fail2Ban (service restart fail2ban). I’m still not quite sure how all this works, since my experience with Linux firewalls is entirely with iptables on CentOS, and even then I generally use Webmin to do my firewall configuration. So, if you see any holes in this strategy, or anything else that needs to be done to tighten up the firewall or make Fail2Ban work as it should, please leave a comment in the comments section!

Configuring E-mail if you elected to install a mail server during Debian installation in part 1:

To configure e-mail if you elected to install a mail server when installing Debian, from a Linux command prompt run:

sudo dpkg-reconfigure exim4-config

How you answer the questions will depend on your installation, and what you want the mail server to do. If you only want to use it to send mail to the Internet (for example, voicemail notifications/recordings), AND your server is on a fixed IP address, you can probably select “internet site; mail is sent and received directly using SMTP” on the first screen, and pretty much accept the defaults from there (this may or may not work if you are on a dynamic IP address — some hosts will reject your mail in that situation). I don’t advise using your PBX server to also handle general e-mail traffic but I suppose that if you have low volumes of voice and mail traffic, you might get away with it.

Limiting access to Apache:

If you installed Apache as I suggested, perhaps you would not like the entire world to be able to get to the login screen of your PBX.  There is a way to limit access to certain IP address, but I will tell you right now that most of the methods you see on the web won’t work.  In particular, using a .htaccess file won’t work (there may be a way to make it work, but I have read those are rather insecure anyway) and in my experience, modifying httpd.conf (which has nothing in it to begin with) doesn’t work (you will either block everyone including yourself, or no one).  What DID work for me was adding lines similar to these to the top of /etc/apache2/apache2.conf (before the initial comments):

<Location />
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
   <— localhost address
Allow from 192.168.0.111   <— an individual IP address
Allow from 192.168.1.0/24   <— a range of IP addresses
</Location>

The above took me THREE hours to figure out, primarily because most of the pages obtained from Google gave other advice that did not work. And people wonder why I do not enjoy trying to figure out these puzzles. All you Linux people who would say that doing something like this “builds character” or “is a good learning experience” can go stick your heads in a bucket of shit and then go jump off a high cliff!

Comments (12)

Installing FusionPBX successfully — Part 1: Installing Debian Linux

After my previous ill-fated attempt to install FusionPBX from a slightly outdated ISO, I sought help on the #fusionpbx IRC channel and was told that the best method of installation is to use the Easy Install found on this page. I followed the instructions on that page, and it installed fine for me.

The first thing I had to do was install Debian Linux (that was the recommended distribution), so I went to the “Installing Debian via the Internet” page and grabbed the i386 version of a “Smaller CD” installer ISO. This version requires a network connection during the install, as you will see, but the advantage is it’s a relatively small download (especially nice if you are doing the install on a remote server or virtual machine). Here are the screenshots from that install — remember you can click on any image to enlarge it:

On the opening screen, I picked a normal install rather than a Graphical Install, because I feared a Graphical Install might automatically install a graphical desktop, which I didn’t want on a server:

The next pages have you make selections for your preferred language, your location, and your keyboard layout.  One thing I noticed is that Debian tends to ask one question per page, whereas in many other distros you might make several choices on a single page.  Therefore there are a LOT of pages…

Next, the installer looks for a DHCP server, so it can get an IP address and connect to the network. If it can’t find one, it will let you know…

If it can’t autoconfigure the network it will ask you what to do.  In this case there was no DHCP server available, so I had to do a manual configuration:

After you have configured your network (or if you don’t have to because the installer found a DHCP server), it asks you to choose a mirror of the Debian archive:

Next you will set up users and passwords.  I suggest you DO NOT set a root password, so that it will create a user account with the power to become root using “sudo”:

Now you are asked to pick a time zone. Seems like this should have been asked back when it was asking for other location information, but oh well…

Now it asks how you want to partition your hard drive.  I suggest using the entire disk and selecting the defaults unless you know what you are doing and have good reason to so something else:

Select yes on this screen to format the disk:

Now there will be some delay while it installs the operating system to the drive:

Note the next question – you can answer it either way, but since I’d prefer that my operating system not be “phoning home”, I answered “No.”

This is the most important selection of the install. Make sure EVERYTHING is unchecked. By default, there are a couple of things checked, and you don’t need either of them at this point. The FusionPBX Easy Install script will install all the software you need, including any necessary system utilities.  The one exception I have discovered is that it does not install a mail server, which you might need if you plan to use any scripts that require the Linux mail command, so you could select Mail server if you think you might need it:

Let it install the GRUB boot loader, of course:

Congratulations, your Debian install is finished!

Continue to Installing FusionPBX successfully — Part 2: Installing FusionPBX.

Comments off

My attempt to install FusionPBX on a VMware server

This is a screenshot record of my first attempt to install FusionPBX right up until the time I decided things were going nowhere, but then after posting this article I was able to get some help from FusionPBX author Mark J Crane in the #fusionpbx IRC channel, so I thought I was back on track until I ran into more issues (more information at the bottom of this article). I used the 32 bit Ubuntu Linux based ISO (2012 May 03 version) from this page. Note that the ISO was released in May, while FreeSWITCH 1.2 (stable version) was released in August – this turns out to be a contributing issue. Another possible contributing factor is that the ISO was created by someone other than the FusionPBX author — again, I’ll have more to say at the end.  But for the moment, my advice is that you NOT use that ISO to install FusionPBX.  However, if it has been updated to some date on or after October, 2012, then go ahead and give it a try.

In the meantime, I am told that the best method of installation is to use the Easy Install found on this page.  It’s not quite as easy as installing from an ISO, but it actually works!.  So don’t do what I did here, at least not until the ISO is updated.  You can read about how I installed it and got it to work starting here:

Installing FusionPBX successfully — Part 1: Installing Debian Linux

Again, this article is the record of my first attempt, which might only be remotely useful to anyone if a new ISO is released. You can click on any screenshot to enlarge it, and you will probably need to on some of the text-only screens.

I selected the option to start the installer directly, but I don’t think it did that (maybe because I took too long to respond):

There was no DHCP server available on the network I was using, which caused the installer some consternation:

Finally a desktop – don’t get too attached to it because it won’t stick around…

And then this notice (I had to scroll it so that’s why two screenshots):

How to get into a terminal program:

Now here is where things got interesting. In order to set up networking, I did have to configure /etc/network/interfaces:

BUT I also had to make a resolv.conf, BUT for some reason resolv.conf actually has to be symlink to another file somewhere.  So, following advice I found on some page on the web, I created it at /run/resolvconf/resolv.conf:

I then created the symlink and restarted networking to pick up the changed settings:

I then clicked on the Install FusionPBX icon on the desktop and went through several configuration screens — on most of them I could accept the defaults:

When you finally see this the install is complete – be sure to remove your install CD or media before restarting:

Again you may get some grief if it can’t find a network right away (this was probably an old screen from one of my earlier install attempts that went away after I got the network configured properly):

When you get here, it’s done (to a point) and you can log in. Note the nice Ubuntu GUI has gone away for good:

If your network still isn’t working you may see a message like the one at the bottom of this screen. This is bad:

But assuming you got your network set up properly, once you log in, you get a message showing the various thing you can do to update the system. And yes, you do need to do these things or the web interface won’t work (it will just give you an error message). Start by answering Y to let FusionPBX upgraded (before it’s all through, you may feel like you’ve installed FusionPBX about three times, which makes me wonder, if they’re just going to blow it away and reinstall anyway, why not ship a minimal install ISO and download the current version in the first place?). And also, the lines that use the install_fusionpbx script won’t work as shown.  See the end of this article for more information.

At the end of the upgrade (or if you skip it) you’ll see this. Note that you cannot log into the server via SSH or connect via the web browser until the keys shown near the bottom of the screen have been generated:

As you go through the other install/upgrade steps that appear in the text message when you first log in, at one point you’ll see this. When this happens, it is very important you log into the web based interface using the address it gives you — there are two screens of configuration there you must complete. PAY ATTENTION to what you are typing in for user name and password on the first screen — if you typo those or forget what you typed, you won’t be able to get into the web interface and you’ll have to start the entire install again from scratch (and I guarantee you that by the time you get to this point, you won’t want to start over!):

PAY ATTENTION to what you type in on this screen!!!

This is the screen you finally want to see. Unfortunately, just because it has installed correctly doesn’t mean it’s actually going to work. :(

Unfortunately, when I was all through, it didn’t work. When I tried to view SIP status (and on a few other screens), this is what I got (and yes, FreeSWITCH was running, though I have no idea if it was running correctly!):

Okay, so here are some things I learned:

First, if you are installing in a virtual machine, don’t be too stingy with memory. 1 GB is probably okay for most home or small office users, 2 GB is better. It depends on how many and which modules you have loaded, and also probably your call volume.  20 GB is probably sufficient disk space for a small installation, but it would be better to have more if  you are planning on having  a large number of users (particularly if they will all have voicemail).

Second, the version of FreeSWITCH supplied on the ISO that I used is apparently not going to work. While I didn’t do all of this personally, I would say if you are very determined to use the May, 2012 ISO (which I don NOT recommend), the proper procedure after the initial install is finished goes something like this:

sudo su (to become root)
cd /usr/src
mv freeswitch freeswitch-bak
git /usr/src/freeswitch
git checkout v1.2.stable
cd /usr/src/install_fusionpbx
./install_fusionpbx.sh install-freeswitch auto
./install_fusionpbx.sh fix-permissions auto
./install_fusionpbx.sh upgrade-fusionpbx user
exit

I may be wrong about this or may have missed a step, but the thing to check for is whether there are modules in the FreeSWITCH modules directory:

cd /usr/local/freeswitch/mod
ls

If there are no modules there, then FreeSWITCH did not install correctly and you will probably need to do the above steps again, in order to back up your existing FreeSWITCH installation, get the latest stable version, and then run the install_fusionpbx scripts.

FusionPBX itself looks like a nice piece of software, and very configurable, but when you do a setup from an ISO image you sort of expect it to actually work. I’m hopeful that a new ISO will appear soon — the developers are aware of these issues — but they advise that you use the Easy Install until the ISO is updated.  I was able to get the ISO to work up to a point, but ran into some strange issues that were more than likely the result of the convoluted install process. The way I finally got it to work is described in Installing FusionPBX successfully — Part 1: Installing Debian Linux.

Comments off

Logitech C910 Webcam (Logitech Webcam Software) crashing on Mac OS X 10.7

This article has been moved. Please click here to read it.

Comments (4)

Link: Can You Believe It? Legislation that Would Actually Help Fix the Patent System

Comments off

For expert, technically inclined Obihai users: Tweaking the Obihai Dial plan

This article has been heavily edited and moved.  Please click here to read it.

Comments (10)

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

This article has been moved. Please click here to read it.

Comments (1)

To the developers of Ubuntu Linux: Please stop pushing updates that break our video drivers!

"XBMC needs hardware accelerated OpenGL rendering" error

In the past couple of years I’ve helped install Ubuntu Linux on four HTPC systems, three of which were Acer Aspire Revos (two are still in use), and the fourth an ASRock Vision 3D. On each of these we’ve had a recurring problem where Ubuntu pushes an update to Linux (which appears in the Update Manager along with other updates) and then you start having video problems, or problems with your HTPC software.  In the most extreme cases, Ubuntu appears to not boot at all – you simply get a black screen.  In reality it has booted and you can SSH into it from another machine (assuming you’ve had the knowledge and foresight to enable SSH access), but the graphic display manager isn’t working, so you either get a blank screen or just text.  In less extreme cases, it will still boot into the desktop but when you try to run your HTPC software (such as XBMC or Boxee), it won’t start.  Instead it may fail with a message similar to “XBMC needs hardware accelerated OpenGL rendering. Install an appropriate graphics driver”.

The problem always seems to be the same and it’s the one I wrote about in the article, If your Linux-based PC with NVIDIA graphics started booting to a black screen or text only, here is the fix — maybe!  I suggest you read that article BEFORE you have the problem!  It’s just getting REALLY annoying to encounter this issue every few weeks, and while it’s happened so often that I now know the drill to fix it, I can imagine that it probably sends new Ubuntu users into full panic mode (I know it really freaked me out the first time I encountered it).

This is not an uncommon problem either. Putting the phrase “XBMC needs hardware accelerated OpenGL rendering” (including the quotes) into Google brings up “About 2,500 results” as I write this. To me that indicates that about 2,500 people, give or take a few, have had this issue hand have been frustrated enough to have posted something somewhere on the Web about it. There are doubtless thousands of others who searched on the phrase and found enough information to fix the problem. And it’s NOT what I’d call an easy fix for someone unfamiliar with using the Linux command line or working outside the Ubuntu GUI.

Every so often I read one of those articles about how the new versions of Ubuntu are so easy to use that even your grandmother could use it. Bzzzzzt! Sorry, that’s wrong, not as long as shit like this happens. Unless you have a very uncommon grandmother, she is probably not going to be able to figure out how to download and reinstall a video driver.

The solution is simple: If you can’t push out Linux upgrades that don’t break our video drivers, then stop pushing out Linux upgrades! Or else, figure out or to make it download and upgrade the video driver at the same time. Or at the very least, pop up some kind of warning message if someone is about to do any update that will likely break things, and give them the option to permanently exclude such updates.

And I don’t want to hear any crap out of anybody about how it’s stupid to install updates if you don’t know what they do. Ubuntu pushes out these updates via their Update Manager software, which pops up and basically nags the user to install the updates. You can close and ignore it, of course, but every so often it will keep nagging you to install the updates.  Users coming from another platform (particularly Mac users) will probably assume it’s okay to install all offered updates.  I just question the wisdom of pushing out Linux kernel updates this way — those are in a totally different category than, say, an upgrade to a new version of Firefox, and yet the user is not in any way warned that a kernel update is a pretty serious upgrade that could cause breakage.

P.S.  Please do NOT get the idea that I am any kind of expert in this stuff.  If you leave a comment asking for help in fixing your system, it’s probably going to sit there like a big old smelly dog turd on the lawn, with no replies at all, unless I or a reader just happens to know the answer, which is rather unlikely!  There are much more appropriate forums for requesting help — please use one of those.

Comments (2)

Why do new versions of Asterisk seem to have more problems?

Priceless screen capture: Set your location in Google to "Hell, MI" because it makes for a more interesting screenshot, and Google hands you "About 666 results"! (No, it's not Photoshopped and yes, there really is such a place!)

As I may have mentioned elsewhere, just within the last couple of weeks we completed an upgrade of an Asterisk server that was getting a bit long in the tooth.  The old server did everything we wanted, but it was time to upgrade to more modern and more energy-efficient hardware.  The old system ran Asterisk 1.4 and FreePBX 2.7 and was pretty rock-solid reliable. The new server runs Asterisk 1.8 and FreePBX 2.9.  All in all the changeover was pretty painless BUT ever since we did it we keep running up against little annoyances that we’re pretty sure have to be the fault of Asterisk, since we didn’t change anything in the configuration that would cause such a thing.

I’m not so much talking about things like the recent issue with outgoing calls to Google Voice, that for some odd reason ONLY seemed to affect Asterisk users.  FreeSWITCH users didn’t seem to have a bit of problem, nor did Obihai devices users.  The only people who had issues were those using Asterisk’s Gtalk channel driver.  I have no idea why that was the case, but that’s not what I’m talking about here.

Nor am I referring to the fact that some of out custom scripts broke because the Asterisk folks, for reasons known only to themselves, decided to break compatibility with previous versions and deprecate the use of the vertical bar character | as a separator in dial plan instructions, replacing it by a comma.  Nor that certain dial plan instructions were deprecated in favor of other forms of the same instruction.  Try doing a Google search on this:

Asterisk “has been deprecated”

When I tried it I got “About 1,850,000 results” and while I realize that you can’t put too much weight in those counts, that’s a lot of hits.  What happens if I run the same search but restrict it to a known VoIP site?

Asterisk “has been deprecated” site:voip-info.org

Even on that one site, that phrase “has been deprecated” in conjunction with Asterisk appears nearly six hundred times (597, actually – or it jumps to 666 if I set my location to “Hell, Michigan” to get a more interesting screenshot – no fooling!).  So the point is that the Asterisk folks aren’t exactly sticklers about maintaining compatibility with older versions.  Most anyone that’s worked with Asterisk knows this.

What’s really annoying is when you have something that worked perfectly well in a previous version, but fails to work under a newer version of Asterisk.  Two example come to mind.  One is that we had a couple of old VoIP adapters made by Leadtek (they had been used with a commercial provider but unlocked) that worked perfectly well for SIP connections to Asterisk under Asterisk 1.4, and that still work fine if you register them with an online service like Voxalot, but simply will not work reliably with Asterisk 1.8.  Another example is something I ran into last night.

For a very long time we’ve used the free version of the Zoiper softphone in our computers to connect back to the Asterisk server using IAX protocol.  Under Asterisk 1.4 this worked great.  Under Asterisk 1.8, we get a very weird problem where the softphone will register with Asterisk and can receive calls, but outgoing calls just won’t work.  The really weird part is that even call transfers work.  If I receive a call on the softphone, I can transfer it to another Asterisk extension with no problem.  But if I just try to originate a call, I get this (and bear in mind, this is using the exact same extension and softphone settings that worked under Asterisk 1.4).  The Asterisk CLI spits out a line like this:

[2011-08-22 02:45:33] NOTICE[3664]: chan_iax2.c:10901 socket_process: Host 192.168.0.57 failed to authenticate as 234

Now keep in mind that extension 234 is already registered — otherwise it could not receive or transfer calls.  Meanwhile, the Zoiper softphone shows the message “facility not subscribed” which means nothing at all to me.  The server and the softphone are on the same local network, so it is definitely not a firewall problem, nor is there a restriction on allowable IP address in the extension settings.  And I am aware of, and tried all possible settings for the “requirecalltoken” setting in the extension’s configuration, and I also tried adding calltokenoptional = 0.0.0.0/0.0.0.0  in the Asterisk IAX settings (I even tried adding it in iax_general_custom.conf).  Nothing helped, and no amount of searching produced a solution.  The really weird part is that this only seems to be a problem if the Zoiper softphone and the Asterisk server are on the same local network.  If the server is located somewhere else out on the wide-open Internet then there seems to be no problem connecting.

I turned on IAX2 debugging from the Asterisk CLI, I looked at logs, and there was nothing to give me any indication of what was wrong.  In desperation I even tried rebooting the system, although that rarely helps anything with this particular system, and it still didn’t help.  The only thing that helped was sending Zoiper to a different server on a non-local system.

There have been other, similar annoyances of things that worked fine under Asterisk 1.4 but not under Asterisk 1.8.  In some cases I think the issues have to do with enhanced security, but what good it security if you can’t use your PBX for its intended purpose (a point that also seems to be lost on the creators of a certain popular FreePBX-based distribution, who are what I consider excessively paranoid about security to the point that you just about can’t run an external extension with their distribution)?

It’s no wonder to me that a lot of users have chosen to stay with Asterisk 1.6 and have no immediate plans to upgrade.  Sometimes you get the feeling that computer software reaches its “peak” after being out a few years, and then after that it’s as if the developers start just “phoning it in”, so to speak.  They can’t leave well enough alone, but if their changes break something that’s heretofore always worked, they just kind of shrug their shoulders and say “oh, well”, or at least that’s how it seems sometimes.

The funny part is that the only reason I upgraded one of the systems I help with to Asterisk 1.8 in the first place was to get the built-in Google Voice capability, and as time goes by I more and more think we should have stayed with Asterisk 1.6 and used some other method to get Google Voice connectivity.  The Gtalk channel driver proved so unreliable for incoming calls that we switched to using Michigan DID’s to bring them in, and again this is an issue that appears not to have affected Obihai device users or FreeSWITCH users, just Asterisk users.

It’s just exasperating, that’s what it is!

Comments (4)

Follow

Get every new post delivered to your Inbox.

Join 136 other followers

%d bloggers like this: