PHP Bug can cause FreePBX Inbound Routes and Asterisk Phonebook entries to not work as expected

 

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

It appears there is a nasty bug in certain versions of PHP (almost certainly in version 5.3.3, and perhaps other versions as well) that can cause SOME inbound and outbound routes in FreePBX to be ignored.  Add this to the list of difficulties to plague some FreePBX users, but for once it’s not something the FreePBX developers did.

The symptom appears to be that you have an inbound route with a DID that starts with the number “2”, or an Asterisk Phonebook entry that starts with a “2”, but it doesn’t work as expected or gets changed to a negative number.  Not all patterns starting with “2” appear to be affected, but ten digit numbers in certain area codes (such as 248 here in Michigan) definitely are.  In the case of inbound routes, it appears that the numbers get stored in the MySQL database correctly, but when they get written out to extensions_additional.conf (the dialplan file that F—PBX generates for Asterisk to use) they get transformed into negative numbers.  Therefore, when a call comes in on that DID, Asterisk doesn’t recognize it and the call gets dropped (or if you accept calls for any DID then it’s handled as such a call, but a warning message is posted to the CLI and the log file).

For a discussion of this issue, see these threads in the PBX in a Flash forum:

Inbound DID routing (only catchall works)
(240) area code in Asterisk Phonebook

Just wanted to alert you to this in case you happen to have the buggy PHP version and things just aren’t working as they should be. The best fix is probably to upgrade PHP to a later version but that can cause other issues, or you may encounter unmet dependencies when trying to upgrade (in fact, if you come across a foolproof way to upgrade PHP on Centos, please let us know). If you are using PBX in a Flash, they’re aware of the issue and one would hope they’ll have a fix real soon now. If you are using any other FreePBX-based distro then you will have to bug the distributors of that distro for a fix. If you rolled your own, then good luck to you in upgrading PHP!

I no longer recommend using Asterisk’s Google Voice support — try these methods instead!

 

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

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

This article was originally written in January of 2012, and has been heavily edited in an attempt to update it a bit.

Not that anyone probably cares what I think, but anyone who regularly reads this blog (or any of the other VoIP-related blog that cover Asterisk) may have noticed that prior to the release of Asterisk 11, Asterisk’s support for Google Voice had become less and less reliable over time, particularly for incoming calls. You have to do all sorts of “tricks” to make it work, and these usually involve adding delays that don’t always fix the problem, inconvenience your callers, and possibly cause more hangups as people get tired of waiting for you to answer the phone.

Therefore, I suggest that if you are using a version of Asterisk earlier than Asterisk 11, you stop using Asterisk’s Google Voice support completely. Assuming that you feel you must keep using an older version of Asterisk, I suggest trying one or more of the following:

  1. Use YATE as a gateway between Asterisk and Google Voice. See Using YATE to overcome Google Voice issues in FreeSWITCH and Asterisk, this article and this forum thread on YATE in a Flash, and this thread on YATE Tips & Tricks). YATE is what powers Bill Simon’s gateway (mentioned below). See comments by Bill and pianoquintet under this article.
  2. Use Bill Simon’s Google Voice-SIP gateway to handle your Google Voice calls. Some people may not want to rely on an external service for this, while others may very much appreciate having the option. I mention it for those in the latter group. For more information see Bill Simon’s Free SIP-to-XMPP Gateway Easily Puts Google Voice on Your VoIP Phone (Voxilla). While the linked articles talk about using the gateway with a SIP device, it can be used as an Asterisk trunk.  EDIT: As of April 7, 2015 the Google Voice Gateway has been relaunched and there is now a one-time fee to sign up.
  3. If your only issue is with incoming calls, you could use a DID to bring the calls into your system.  But keep in mind that Google Voice does not like it when calls are answered the moment they connect, so in your FreePBX Inbound Route be sure to set the “Pause Before Answer” option to at least 1.  I have found that a 1 second pause is sufficient, but I’m not saying that is the correct value for everyone, or even that everyone will need to include such a pause (some DID providers may delay the call sufficiently before connecting through to your system that the pause isn’t needed).

At this point, any of those would likely produce better results than using the Google Voice support in any version of Asterisk prior to Asterisk 11.

EVERYTHING in this article is my personal opinion.  Nothing here should be taken as a statement of fact.

EDIT:  Ward Mundy reports that he just may have found a workaround for the incoming calls issue — see this thread in the PBX in a Flash forum.

Interesting thread on integrating Speech to Text with Asterisk and PBX in a Flash

 

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

I just wanted to call your attention to this thread on the PBX in a Flash forum:

Exploring Speech to Text

This thread explores the possibility of adding a simple speech to text demo, and also discusses the possibility of transcribing e-mails to text.  It uses Google’s speech recognition service, and it is free to use.  I doubt you would be free to use it in any commercial application, but for those that just like to tinker with new capabilities for your Asterisk server, you might find this interesting.

I haven’t personally tried it yet, but I will say that if you are using some FreePBX based distro other than PBX in a Flash, you may need to remove the calls to the Flite speech synthesizer (or install Flite support).  I hate Flite (I think the voice quality sucks harder than a black hole — okay, maybe I exaggerate a little, but Cepstral voice synthesis is much better than Flite — unfortunately Cepstral is not free) so I’m not going to tell you how to install it.  Flite’s only used in the demo in the first post so if you are trying to do something else (such as attempt voicemail transcription, as discussed in the thread) you probably don’t need it anyway.

What would be nice would be the ability to dial a code, record a short message, and then have a transcription e-mailed to the address you use for voicemail notifications.  THAT is something I’d actually use on occasion!

EDIT: After posting this, I tried a basic installation on a NON-PBX in a Flash system.  Besides removing the references to Flite, I found I had to do the following:

  1. Change ownership of /var/lib/asterisk/agi-bin/speech-recog.agi to  asterisk:asterisk
  2. Install the perl modules mentioned in the “use” statements in /var/lib/asterisk/agi-bin/speech-recog.agi
  3. Install flac (some users may also need to install sox, but I had installed that previously).

How to give a particular extension or group of extensions access to a specific trunk or group of trunks for outgoing calls in FreePBX

 

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

I’m going to lift a bit of preliminary text from a page on the FreePBX site entitled “How to give a particular extension different or restricted trunk access for outgoing calls“:

IMPORTANT: When implementing any sort of restrictions on extensions, using the method described here or any other method, please be absolutely certain that you do not inadvertently restrict access to emergency services numbers (such as 911 in the U.S./Canada)!

There is a recurring question that comes up every so often, regarding how to give one particular extension (or a group of extensions) access to a different trunk for specific outgoing calls, or perhaps to restrict access to a particular trunk. Usually this involves an extension that is accessible to people that might want to make calls that cost money, and you don’t want them to do that. But there are many other reasons to route calls differently for different extensions, while still keeping all extensions on the same system so they can call each other.

Usually when someone asks about this, a common suggestion is to use the unsupported third-party Custom Contexts module. While this module is very versatile and lets you have a high degree of control over what each extension may access, there are at least two downsides. One is that it’s not part of the official distribution and therefore, a future upgrade of FreePBX might “break” it.

(This is probably less likely now, because it appears some of the FreePBX developers have taken an interest in maintaining it, but it’s still not beyond the realm of possibility.)

The other issue is that you have to go through and check (and maybe change) all the priority dropdowns if you add, remove, or move a route, and that can get to be a pain in the butt very quickly if you are in the habit modifying your routes with any frequency.

The problem with this page is that although it discusses several alternatives to using Custom Contexts (and you may wish to read it just to learn about those other possibilities), it is getting rather dated and therefore does not mention the use of the fourth field in Outbound Routes, a.k.a the “CallerID” field, which is by far the easiest way to implement this.

Let’s say you have an existing outbound route, over which your outbound calls normally travel, and it has a particular selection of trunks.  But you also have an extension, let’s say it’s extension 234, and you want it to use a different trunk or group of trunks.  In FreePBX 2.9 or later, all you have to do is this:

  • Go to the settings page for the Outbound Route that is currently used for outgoing calls.
  • At the bottom of the page, next to the “Submit Changes” button, there is a new “Duplicate Route” button.  Click on “Duplicate Route”.
  • Move the duplicated route to be higher in priority than the original route (it should appear just above the original route in the right-hand column).
  • Optionally rename the duplicated route to something more to your liking.
  • In the duplicated route, under “Dial Patterns that will use this Route“, add the extension number (or pattern matching a group of extensions) to the fourth (CallerID) field of EVERY dial pattern on the list.  Or, if using the Swiss Army Knife Module and you have checked the “Turn On Old (Pre 2.8) Dial Plan Textbox” checkbox (EDIT: or if you have FreePBX 12 or later, and under Settings | Advanced Settings, in the “GUI Behavior” section you have set Enable The Old Style FreePBX Dial Patterns Textarea to True), then add the extension number or pattern to the end of every existing pattern, separated by a forward slash.  As an example, an existing pattern of 1+NXXNXXXXXX would become 1+NXXNXXXXXX/234.  Again, you must do this to every pattern in the pattern list.
  • And finally, in the duplicated route, change the the “Trunk Sequence for Matched Routes” to include only those trunks that you want that extension or group of extensions to use.

If there are additional Outbound Routes for which you want to change the trunk selection for the same extension, repeat the above, starting with the other outbound route(s).  If you have additional extensions and you want one or more of them to have different trunk usage, repeat the above, using the different extension number(s) in the CallerID field and the different trunk selections.

If you want to block an extension’s ability to make toll calls, use the same procedure but only give them access to an ENUM trunk.  ENUM is pretty broken then days, it it would be rare for a call to actually complete, but if it does it’s not going to cost you anything.  This particular usage is discussed in more detail in “How to block a single extension’s ability to make outgoing toll calls in FreePBX“. (EDIT: In the most recent versions of FreePBX you can simply not select any trunks at all in the “Trunk Sequence for Matched Routes” section of the Outbound Route, and then optionally select a failure announcement or whatever treatment you want to give the call in the “Optional Destination on Congestion” section.)

And again, please note that you can use a single extension number OR a pattern in the CallerID field.  For example, if you had a pattern like 1NXXNXXXXXX, you could do something like:

  • 1NXXNXXXXXX/100 – match on the pattern only if the call is from extension 100
  • 1NXXNXXXXXX/2[45]X – match on the pattern only if the call is from an extension in the range 240-259
  • 1NXXNXXXXXX/3XX – match on the pattern only if the call is from an extension in the range 300-399

And if you wanted to allow the call only if it came from extension 100, 240-259, or an extension in the 300’s then you could use all three of the above rules in the same outbound route.

I will offer my opinion that using the Swiss Army Knife Module and checking “Turn On Old (Pre 2.8) Dial Plan Textbox” is the only way to go if you happen to have several hundred dial patterns!  Well, maybe not the only way (you could export a .CSV file, edit it, and import it back in), but definitely the easiest, because you can simply cut all the patterns from the textbox and paste them into a text editor, then use search-and-replace to add the extension numbers, then copy the changed patterns from the text editor and paste them back into the textbox in the Outbound Route.  If the search-and-replace function supports regex matching then it’s easy – set the find string to n and set the replace string to /234n (assuming 234 is the extension number you want to add), and replace all occurrences (be sure to check the first and last lines to make sure they look as they should, in case there was a missing or extra newline character somewhere).

EDIT: We have been informed that the old-style textboxes are once again available in FreePBX 12 and later. You have to click on the Settings tab, then Advanced Settings, then find the “GUI Behavior” section and change the Enable The Old Style FreePBX Dial Patterns Textarea setting to True.

Related Articles:

How to send an e-mail notification when someone dials a particular number in FreePBX

 

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

Someone in the PBX in a Flash forum wanted to know if there was some technique that could be used to get an e-mail alert if a user on the system dialed 911.  There are probably many ways this could be done, but here was the way I thought would work.  This has not been tested in a working installation so please note the disclaimer at the end of the article.  I DO NOT guarantee that this will work on your FreePBX installation!

EDIT (November 24, 2012): Another approach to doing this would be to add some custom dialplan to the [macro-dialout-trunk-predial-hook] context in extensions_custom.conf.  See How to use the FreePBX [macro-dialout-trunk-predial-hook] macro and regular expressions to blacklist or whitelist outgoing calls on all trunks for more information on this technique, which would allow you to easily detect outgoing calls to a particular number on just about any trunk with only a few lines of code, eliminating the need to create a CUSTOM trunk as shown below.  Either method will work, so do whichever you’re more comfortable with.

1. First, add a small additional context to /etc/asterisk/extensions_custom.conf (note that you will probably need to copy and paste this into a text editor to get the first line of the context complete and without line breaks where they shouldn’t be):

[custom-notify-email] exten => _X!,1,TrySystem(echo "This is to notify you that ${CALLERID(name)} at ${CALLERID(num)} has called 911" | mail -s "911 call notification" you@youraddress.com)
exten => _X!,n,Goto(from-internal,0000${EXTEN},1)
exten => h,1,Macro(hangupcall,)

Note that the first line of the context (not counting the context label line) contains the actual email to be sent.  Replace the various elements of the e-mail (body, subject, destination address) with appropriate elements for your situation. In the second line of the context, note that I’m prepending a four-digit code of  “0000” to the number dialed before sending it back into the dial plan.  This code can be anything you want and any number of digits you want, but it should start with something that a user would never dial when making a regular call.  Therefore, things like “0000”, “111111”, or even “*****” could be good choices, while “9876” would be a poor choice because a user might actually attempt to call a number such as “987-6911”.  One PBX in a Flash forum user reported that “0000” conflicted with Astridex in some way, so that’s why I’m taking pains to explain this.  Since the user isn’t expected to dial these digits, you could even use something like “010100001111”, just as long as it’s a code used uniquely for this purpose.

2. Create a CUSTOM trunk. Make the trunk name whatever you like, but for the Custom Dial String use:

Local/$OUTNUM$@custom-notify-email

When you set it up it should look like this:

CUSTOM trunk (here named Send-email-notification) sends calls to custom-notify-email context

3. Assuming you’re using this to monitor 911 calls, create a NEW emergency 911 Outbound Route that duplicates your existing 911 route (In FreePBX 2.9 or later you can click on the “Duplicate Route” button). In the duplicate (which should be right underneath the original in priority) change the dial pattern from 911 to 0000|911 (but if you used something other than 0000 in step 1, use the same thing here).  What this does is strip off the digits that were prepended to the number by the custom-notify-email context — this is done so you don’t create an endless loop. Note the pattern I have shown assumes you are using FreePBX 2.7 or earlier OR are using the Swiss Army Knife module to restore the pre-2.8 dial pattern text box in your Outbound Routes — if you haven’t done that then be sure you get each component of the dial pattern in the correct little box.

DUPLICATE of original 911 emergency route that strips prepend in dial pattern (route has been renamed to 911-strip-prepend). Note how Swiss Army Knife module restores textbox entry for dial patterns!

4. In your ORIGINAL emergency 911 Outbound Route, change the trunk selection to use only the CUSTOM trunk you created in step 2.

ORIGINAL 911 emergency route, with trunk selection changed to use CUSTOM trunk

That’s it. The call flow is as follows:

Someone dials 911, it goes to the original 911 outbound route, then to the custom trunk and from there to your custom context which sends the email, prepends 0000 (or the digits you have used instead) onto the number (for example, making it 0000911 internally), and sends it back to the from-internal dial plan. It hits the duplicate 911 outbound route which strips the prepended digits and sends the call to your original trunk selection for 911 calls.

I would STRONGLY urge you to make a test call and see if it all works as you expect, if your local 911 service allows you to do that (call them on the non-emergency number first to make sure it’s okay). See the disclaimer below!!

You could use this same technique for non-emergency calls, but you’d have to have an Outbound Route dedicated to just those calls (in other words, it should only contain dial patterns for the calls you are trying to monitor, and it needs to be higher in priority than any other Outbound Route that might ordinarily handle such calls.  Once you have that working you can apply the above technique, which among other things means you’ll be making a duplicate of that Outbound Route, and making adjustments to the original and the copy as described above.

Disclaimer: The above is just a suggestion of what SHOULD work, and should be considered UNTESTED. Do NOT rely on it until you have tested it yourself to make sure it works as you expect. I don’t guarantee it will do anything except take up more space on your hard drive, so it is solely up to YOU to make sure it works as you want.

How I upgrade Asterisk 1.8

 

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

Note: This article was originally posted in August, 2011 and is very out-of-date.

This is just one of those things that I figured it might not hurt to put into a blog post so I can find it later if I ever need to.  This is the procedure I use to upgrade Asterisk 1.8 when a new release appears that has a fix that I feel I need, or that closes a security hole.  PBX in a Flash users should NOT do this, and FreePBX Distro users probably shouldn’t do this either, as you have your own respective upgrade mechanisms.  This is for folks who have either built a system from scratch, or who (like me) started out with a distro but the decided to go your own way as far as upgrades are concerned.  Note that I am only saying that this is how I do it.  I am NOT telling you to do it this way, and if you do so you do it at your own risk.

There are the steps from the CentOS Linux command prompt.  Some of them need further explanation and those have a footnote number next to them.  Do NOT enter the footnote number from the command prompt! Also, in these examples I’m using Asterisk 1.8.5.0 (the current release version as I write this) as the version I’m installing, but you should go to http://downloads.asterisk.org/pub/telephony/asterisk/releases/ and find the current version and use that instead.  If the lines overflow the width of the column, you should probably copy and paste the entire block into a text editor so that you can see the complete lines and know where the line breaks are supposed to be.

cd /usr/src
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.8.5.0.tar.gz ¹
tar xvfz asterisk-1.8.5.0.tar.gz ¹
cd /usr/src/asterisk-1.8.5.0 ¹
make clean
contrib/scripts/get_mp3_source.sh
./configure
make menuselect ²
/root/stopnoise ³
make
make install

After doing this I find it’s easiest to just reboot the system to nip any “weirdness” in the bud. Some Linux purists will hate that idea (it seems to be a badge of pride among some of them to see how many days they can run a system without rebooting), and if you don’t want to reboot, feel free not to — it’s your system. Many people will stop Asterisk before starting the upgrade procedure by doing amportal stop at the beginning, and amportal start at the end, but since I usually reboot anyway I’ve never found the need to do that (the upgrade seems to go just fine even if Asterisk is running at the time, so I’m not sure why so many people think they have to stop Asterisk first — probably a case of one person did it, so everyone else follows like lemmings to the sea). However, if you don’t plan on rebooting, then you must stop and restart Asterisk to get it to use the upgraded version.  If I want to only restart Asterisk for some reason, I usually go into the Asterisk CLI and do “core restart when convenient” so that the system will restart as soon as there are no calls in progress.

I do NOT use the flite synthesized voices (I can’t stand them; they are far too mechanical for my taste) so you won’t find any instructions here pertaining to those.

Now the footnotes:

¹ Use the correct version number for the version of Asterisk you are installing in place of 1.8.5.0

² When you run “make menuselect” it will bring up a menu that lets you select various options. You will want to pay attention to what is selected and what is not. Typically I need to make these changes:

Under Add-ons, I select everything EXCEPT chan_ooh323 — most of the others are required for FreePBX to function properly. Under Applications, I use the defaults. Under Bridging Modules through PBX Modules, everything that is not X’ed out is selected. Under Resource Modules everything that is not X’ed out is selected except res_pktccops (NOTE: If res_srtp has XXX next to it and you would like to enable SRTP support, stop here and read the note at the bottom of this article). Under Test Modules NOTHING is selected. Under Compiler Flags, LOADABLE_MODULES is selected by default and in addition I select G711_NEW_ALGORITHM and G711_REDUCED_BRANCHING. Under Voicemail Build Options through Module Embedding I just accept the defaults. Under Core Sound Packages through Extras Sound Packages I accept the defaults and also add the sounds corresponding to the language and codecs I use on my system (in my case the *-EN-WAV and *-EN-ULAW packages, and if I had any wideband endpoints I’d also use the *-EN-G722 packages). So, the only screens on which I make changes (in other words, I don’t just accept the defaults) are the Add-ons, Compiler Flags, and the three sound-related screens. Note that the Compiler Flags are just a personal preference (I just think the new algorithm may make G.711 calls a bit clearer) and the sounds MAY not need to be reloaded on every upgrade, but I’d rather be safe and include them, just in case some of the sound files have been updated.

³ This is a bash script I have in my /root directory that contained the following three lines prior to Asterisk 1.8.12.0:

#!/bin/bash
sed -i 's/ast_verb(4, "ast_get_srv: SRV lookup for/ast_verb(11, "ast_get_srv: SRV lookup for/' main/srv.c
sed -i 's/ast_verb(4, "doing dnsmgr_lookup for/ast_verb(11, "doing dnsmgr_lookup for/' main/dnsmgr.c

Starting with Asterisk 1.8.12.0 it appears they changed the default value in the last line, so now I use this:

#!/bin/bash
sed -i 's/ast_verb(4, "ast_get_srv: SRV lookup for/ast_verb(11, "ast_get_srv: SRV lookup for/' main/srv.c
sed -i 's/ast_verb(6, "doing dnsmgr_lookup for/ast_verb(11, "doing dnsmgr_lookup for/' main/dnsmgr.c

If either or both of the phrases “doing dnsmgr_lookup for …” and/or “ast_get_srv: SRV lookup for …” are familiar (and annoying) to you, then you may want to use this script. Otherwise, you can just skip this instruction. For more information, see this thread in the PBX in a Flash forum.

NOTE REGARDING MISSING SRTP SUPPORT: It is possible to add this by following this procedure:

In your browser go to ftp://ftp.owlriver.com/pub/local/ORC/srtp/ (your browser must support the ftp protocol – try Firefox if yours doesn’t). You should see a file named srtp-1.4.4-1orc.src.rpm or perhaps a newer version. Download it and then move it to a directory (such as /tmp or /root) on your Asterisk server. Then do this, changing the version number if you got a different one:

cd (whatever directory you put the file into)
rpm -ivh srtp-1.44-1orc.src.rpm
cd /usr/src/redhat/SOURCES/srtp

(If the srtp directory does not exist then cd /usr/src/redhat/SOURCES/ and tar xvf srtp-1.4.4.tgz)
./configure
make
make install

Then go back and restart the upgrade procedure, starting at the second cd … command and make clean. When you get to make menuselect, res_srtp should now be enabled. Note that this is not the only thing you need to do to make SRTP functional; at a bare minimum you would beed to add the line encryption=yes to the extension’s configuration, and even that would not be sufficient for some devices due to a so far unpatched bug in Asterisk. But, that is beyond the scope of this article.

How to block a single extension’s ability to make outgoing toll calls in FreePBX

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission.
Courtesy Phone
Image by zacklur via Flickr

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

This question comes up a lot and rather than having to re-type the answer each time I see it posted in some forum, I decided to put it here, where I can just link to it.  If you want to know why this works, read my previous article, Asterisk hiding a useful feature in plain sight by giving it a “cute” name.

Many organizations have a single extension that is a “house phone” for visitors, and they don’t want anyone to be able to use that phone to make “off-site” calls.  The thing you must decide is, do you want your users to only be able to make in-house calls, or do you want to in addition allow calls to local and toll-free numbers? It makes a bit of difference in how you do this.  And remember, in most places, by law you MUST allow calls to 911 or whatever your local emergency number might be — if you block emergency calls and someone tries to use that phone to summon an ambulance or get other necessary emergency help and is unsuccessful in doing so, then prepare to have your butt sued off (and possibly even serve some time in prison), and I don’t have a bit of sympathy for you.  I don’t care what reasons you may think you have for wanting to block emergency calls, just DON’T DO IT.

Anyway, here’s the basic technique:

1.  Create a Trunk: (EDIT: This step is unnecessary in the most recent versions of FreePBX). If you want to allow “free” off-premises calls, then the easiest thing to do is create an ENUM trunk, if you haven’t done so already.  If you DON’T want to allow free calls, then create a “dummy” trunk for the purpose.  Create a CUSTOM trunk (not SIP or IAX2, etc.), name it Blocked, and make the Custom Dial String Local/congestion@app-blackhole — that’s all you have to do. For extra safety, you can also check the “Disable Trunk” checkbox (this should play a recording saying that all circuits are busy, or something to that effect, whereas leaving the trunk enabled would play “fast busy” tones). Then submit the changes.

2.  Create an Outbound Route: Give the Outbound Route any name you like. In the “Dial Patterns that will use this Route” section, enter the patterns you do NOT want the extension to be able to dial (in the third field of a pattern if using FreePBX 2.8 or higher) followed by the extension number that you want to restrict (in the fourth field in FreePBX 2.8 or higher, or after a forward slash character if using a lower version).  I’m going to show the following examples in the syntax used in FreePBX 2.7 (EDIT: you would also use this syntax in FreePBX 12 or later, if under Settings | Advanced Settings, in the “GUI Behavior” section you have set Enable The Old Style FreePBX Dial Patterns Textarea to True).  Let’s say you want to block calls from extension 234:

To block all calls of 11 digits or more (in case you have “local” 10 digit dialing):
XXXXXXXXXXX!/234

To block all calls of 8 digits or more (allowing 7 digit local calls):
XXXXXXXX!/234

To block all calls of 4 digits or more (in case you have three-digit extensions and want to allow in-house and 911 calls only):
XXXX!/234

In the Outbound Route trunk selection, (EDIT: if you have a recent version of FreePBX, simply do not select any trunks at all in the “Trunk Sequence for Matched Routes” section of the Outbound Route, and then optionally select a failure announcement or whatever treatment you want to give the call in the “Optional Destination on Congestion” section. Otherwise, if you are still running an older version of FreePBX) select whichever trunk you created in Step 1 (ENUM or Blocked).  Select only that one trunk.  Note that if you “disabled” the Blocked trunk it may be grayed out, but you still should be able to select it as a trunk choice, and that should be sufficient to keep FreePBX from complaining that you haven’t made a trunk selection.

Priority is important! Make sure this Outbound Route appears in your list of Outbound Routes BELOW any routes that handle calls you want to allow (your emergency route(s) for sure, and possibly routes that handle Toll-Free calls if you want to allow those), but ABOVE any routes that would normally be used for the type of calls you want to restrict.  Remember that this route will only restrict calls that match the patterns, so if you only restrict calls that are 8 digits or more and you have a lower-priority route that handles 7-digit local calls, those calls should still go out.

Just a note about use of an ENUM trunk (EDIT: Optional and not necessary in newer versions of FreePBX).  If someone calls a number that is registered as an ENUM number, it will go out as a direct SIP call, bypassing your normal SIP or IAX providers, so it won’t cost you a dime.  The vast majority of numbers are NOT reachable via ENUM so if you use an ENUM trunk as your “blocker” trunk, it will be a very rare thing if a call actually connects that way, but if it does you won’t be paying for it.  Sometimes U.S. or Canada Toll-Free numbers are reachable via ENUM and sometimes they are not — it’s actually pretty much a crap shoot whether it will even work at all.  So if you want to specifically allow toll-free calls, don’t count on ENUM to handle them, but be aware that in some cases they might go through via ENUM, at no cost to you (other than whatever you may pay for your Internet connection, of course).

Be sure to make some test calls from the extension to make sure everything works as you expect.  And double-check to make sure you have not blocked emergency (911, or whatever your local number is) calls!

If you need to do blocking for more than one extension, you can either use patterns (rather than single extension numbers) after the forward slash, or simply add new blocking rules.  For example, you could do this:

Block all calls of 4 digits or more from extension 234 or 235:
XXXX!/23[45]

Block all calls of 4 digits or more from extension 230 through 239:
XXXX!/23X

Block all calls of 4 digits or more from extension 234, and block all calls to 1-900 numbers from extension 288:
XXXX!/234
1900XXXXXXX/288
900XXXXXXX/288

 

How to keep one group of extensions from being able to call another group of extensions in FreePBX

 

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

FreePBX is NOT designed for multi-tenant use. Yet a lot of people will still try to, for example, run two small companies off the same FreePBX server. The question then invariably arises “How do I keep one company’s users from calling the other company’s extensions?”

Just yesterday in the FreePBX forum, someone asked:

Imagine I have extensions 100-110 and I name those CustomContext “GroupA” and I name 200-210 as “GroupB”. Can anyone tell me how I’d eliminate GroupA and GroupB from dialing each other?

And I replied as follows:

Create two new contexts in /etc/asterisk/extensions_custom.conf (just add these to the bottom of the file):

[from-group-a] exten => _2XX,1,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

[from-group-b] exten => _1XX,1,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

After you do that:

Go to the extension configuration page for each extension in Group A and change the context from from-internal to from-group-a.

Go to the extension configuration page for each extension in Group B and change the context from from-internal to from-group-b.

The way this works is if someone in Group A attempts to call an extension in the 200-299 range, OR if someone in Group B attempts to call an extension in the 100-199 range, the call is diverted to “congestion” (a fast busy signal). Otherwise, the call goes to the from-internal context and is processed in the normal way.

No nice way to do this from a GUI page, unfortunately. But, this is pretty simple, I think.

EDIT: There may be a slightly more elegant way to do this, that only involves adding ONE additional context to /etc/asterisk/extensions_custom.conf:

[from-restricted-exts] exten => _2XX/_1XX,1,Goto(app-blackhole,congestion,1)
exten => _1XX/_2XX,1,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

Then you would change the context for all “restricted” extensions from from-internal to from-restricted-exts — this should have the exact same effect as the above contexts (if you don’t understand why, see Asterisk hiding a useful feature in plain sight by giving it a “cute” name).

What I did not really go into in that reply is that this does NOT provide 100% separation.  Although it prevents a user in one group from calling a user on the other directly, it does not address a host of other issues that could arise.  Just as one example, there is nothing that would stop a user in “Group A” from transferring a call to a user in “Group B”.  Did I mention that FreePBX is NOT designed to be a multi-tenant system?

Probably the best solution for multi-tenant use is to run separate installations of Asterisk and FreePBX for each tenant.  You can run them on separate servers, or on separate Virtual Machines on the same server, but be careful if you do the latter, because some VM’s work better than others for the purpose.  The PBX in a Flash folks would tell you, for example, that they’ve never had a problem running PBX in a Flash under Proxmox, but always seem to have issues if trying to run it under VMware.  But others will say that with the right tweaks (and by installing VMware Tools) they’ve made it work under VMware.  But I think that if you only have one server available, running two installs of Asterisk and FreePBX in Virtual Machines is better than trying to make FreePBX (and perhaps Asterisk itself) do something it is clearly not designed to do.

Asterisk hiding a useful feature in plain sight by giving it a "cute" name

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
easter eggs in the stage of painting
Easter Eggs (Image via Wikipedia)

Somewhere in FreePBX 2.7 or thereabouts, it became know that there was a feature of FreePBX Outbound Route dial patterns, were you could use a /CallerID extension. This (among other things) basically lets you limit the use of an Outbound Route to a particular extension or group of extensions.  It’s a very useful feature, but wasn’t widely announced or promoted at the time.  I finally figured out why.

Thing is, it’s NOT a FreePBX feature, it’s a feature of Asterisk.  Anywhere in an Asterisk dial plan where you have a line that starts with

exten => _somepattern,…

you can use the Caller ID modifier, like this:

exten => _somepattern/callerid,…

In which case the pattern won’t be matched unless the current Caller ID number (which on an internal call is the number of the calling extension) matches whatever you’ve replaced callerid with.  Callerid can itself be a number or a pattern.

The real kick in the head is that it appears this feature has been around for a LONG time.  It was definitely in Asterisk 1.4.  Yet virtually none of the documentation you see on Asterisk even mentions this feature.  It might as well have been an “Easter Egg” hidden in the software, for all anyone knew of it.  Well, I finally figured out why — the Asterisk folks hung a “cute” name on it, and it stuck.

They called it ex-girlfriend logic.  The idea is that you can use it to stop an ex-girlfriend from bothering a particular user on your system (at least in raw Asterisk, though I don’t think that’s directly supported in FreePBX).  Besides being a bit sexist, it’s also about the last terminology anyone would think to Google on if they were trying to find out about this feature.  So while people were writing third-party modules like Custom Contexts and Outbound Route Permissions in FreePBX, it now turns out that essentially the same basic functionality was there all along, but hardly anyone (at least in the FreePBX world) knew about it until around about the time of FreePBX 2.7 or so.  If you can find anything at all about this feature in “official” Asterisk documentation (that doesn’t include third-party sites!), you’re a better searcher than I.

Makes you wonder if there are any OTHER cool features in Asterisk that are hidden in plain sight, under unfortunate descriptive names that no one would ever think to use when searching for such a feature!

 

A Perl script to rewrite the "static" IP address in the FreePBX Asterisk SIP Settings when it is changed by your ISP

 

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

This was originally posted in August, 2011. Unless you are deeply in love with Perl, I suggest you also take a look at the newer article, A Bash script to rewrite the "static" IP address in the FreePBX Asterisk SIP Settings when it is changed by your ISP. Although it is still considered experimental, it is simpler than the script shown here, does not require the installation of additional modules, and the text has been updated somewhat to reflect the changes in FreePBX since this article was written.

This post is going to be a bit long because I first need to explain the “why” behind this script, then how to obtain the prerequisite Perl modules, then the script itself and how to test it after installation.

If you are using a recent version of Asterisk and FreePBX you may be using the Asterisk SIP Settings module (under the “Tools” tab) to automatically set various SIP parameters.  This module is a great help to those who don’t know what they are doing, but there is a trap for the unwary (and in this case it’s NOT the fault of FreePBX – it’s a longstanding bug in Asterisk that’s the problem).

At the top of the Asterisk SIP Settings configuration page, in the NAT Settings section, there are two options that can be set.  The first is NAT and there are four possible choices:

  • yes = Always ignore info and assume NAT
  • no = Use NAT mode only according to RFC3581
  • never = Never attempt NAT mode or RFC3581
  • route = Assume NAT, don’t send rport

In theory, if you have a fixed IP address AND your Asterisk server is not behind an external router that does NAT translation, you should use “no” (and most of the rest of this article will not be relevant to you).  This article is intended more for home and SOHO users that both have their Asterisk server behind a hardware router of some kind, and that get their broadband service from a company that occasionally changes their IP address without warning.  For such users, the preferred setting is “yes”.  I’m not enough of a networking guru to tell you under what circumstances one of the other settings might be appropriate (if you understand this stuff, feel free to leave a comment and enlighten us).

FreePBX: Asterisk SIP Settings page, NAT Settings (Public IP Option)

It’s the next set of settings that can get us into trouble.  This is the IP Configuration and there are three possible choices:

  • Public IP
  • Static IP
  • Dynamic IP

If your IP address never changes AND you aren’t behind a hardware firewall then you can usually just set this to “Public IP” and let it go at that.  You will not be asked to fill in any other values.  But most users that are not in that situation will pick one of the other two choices, and this is where the problem arises.  Conventional wisdom has it that if your ISP ever changes your IP address without advance warning (which is the case for most cable broadband and DSL users), you should use the Dynamic IP setting.  In this case there is an auto-configure button that will fill out the fields for you, although you may need to fill in the Dynamic Host field yourself.  This is the “External FQDN as seen on the WAN side of the router and updated dynamically, e.g. mydomain.dyndns.com” (as explained if you mouse over the words “Dynamic Host”).  You can use a DynDNS address (or an address from a similar service) or an address you have purchased.  But the problem is that for some users, THIS METHOD SIMPLY DOES NOT WORK.

FreePBX: Asterisk SIP Settings page, NAT Settings (Dynamic IP Option)

If you try to use Dynamic IP and it won’t work for you, what happens is you will get all sorts of weird errors.  You may get one way audio, some calls may disconnect for no apparent reason after about five seconds, and you will see other weird errors in your CLI.  If you change this setting to “Static IP” and click the auto-configure button and then submit the changes, the problems magically go away – UNTIL your ISP changes your IP address, at which point you suddenly have no connectivity to the outside world.  If you ask for help, everybody and their brother will tell you to use the Dynamic IP setting, and the minute you try that you’ll get all the weird errors again.

FreePBX: Asterisk SIP Settings page, NAT Settings (Static IP Option)

So if that’s your situation, you need this Perl script.  Coupled with a cron job, it goes out and checks your IP address every five minutes and if it notices it has changed, it changes it in the MySQL database (same as if you entered it into the External IP text box on the Asterisk SIP Settings configuration page) and then reloads Asterisk.  Therefore, you can use the Static IP method and it hopefully it will work reliably.  If and when your IP address changes, you should only be down for about five to ten minutes at most (hopefully your broadband provider usually does such changes in the middle of the night!).

Prerequisites:

You still have to use a Dynamic DNS service to keep track of your IP address if you want external extensions to be able to find your server on the Internet.  It’s not required for this script to work, though, so I won’t say any more about that except to note that if you use a recent vintage hardware router, it probably has DDNS support built in.

You may have to install some Perl modules on your system.  This script uses two or three: WWW::Mechanize (only if you use the first variation of the script shown below), Data::Validate::IP, and DBD::mysql.  There are typically two ways to install any missing Perl modules on your system.  One is to do this from the Linux command prompt:

perl -MCPAN -e shell

This will put you into a Perl CPAN shell and if it’s the very first time you’ve ever run this, it may ask you to do some configuration first.  Go ahead and do it.  If you don’t know how to answer a particular question, accepting the default is usually a pretty safe bet (if you disagree with me on this, then you know enough to know how to answer the questions, so you don’t need my help). However there are a couple questions related to buffers where you have the option to not create one, and I usually don’t because I don’t spend much time in the Perl shell.  Just read the questions and either use the default answer, or another suggested answer that fits your preferences.  When it comes time to pick servers (from which you will download modules), just pick two or three that are close to you.

After you’ve done the configuration, just install each module (if you already have it, it may say “nothing to do” and stop).  Alternately, if you configured Perl to ask before downloading dependencies, you may need to answer “yes” a few times to allow dependencies to be downloaded and installed. To install the required modules from within the CPAN shell, just do these, one at a time:

install WWW::Mechanize (only if you use the first variation of the script)
install Data::Validate::IP
install DBD::mysql   (you might already have this).

To quit the CPAN shell, just type quit and press Enter.

Alternately, in some distributions you can get certain Perl modules from the distribution’s repository.  For example, in Centos you may be able to use:

yum install perl-WWW-Mechanize.noarch (only if you use the first variation of the script)
yum install perl-Data-Validate-IP.noarch
yum install perl-DBD-MySQL.noarch

Or in any Debian-based Linux, including Ubuntu Server, try these:

sudo apt install libwww-mechanize-perl (only if you use the first variation of the script)
sudo apt install libdata-validate-ip-perl
sudo apt install libdbd-mysql-perl

It’s likely you already have the Mysql module. Depending on your distro you may have to leave off the .noarch, or find a specific version in an appropriate repository.  Installing from the CPAN shell make take a bit more time for the initial configuration, and some people find the CPAN shell difficult to use, but you will always get the correct version of the module.

Note that if you use Webmin, there is a third way – you can install modules from the Other | Perl Modules | Install Module page.  BUT, that may not work correctly until you have configured CPAN as mentioned above.  Don’t let that stop you from trying it, though!

The Script:

There are now two versions of this script. One uses WWW::Mechanize to get your IP address from a web site that returns only your IP address, while the second uses a dig command to get your IP address. We recommend the second one, since public sites that return only your IP address have a nasty habit of disappearing. Note that as always, these WILL overflow the lines in WordPress, so you will want to cut and paste your preferred script into a text editor.  Also note that WordPress MAY change apostrophes and quotes into “prettified” versions, and if it does that will totally mess up Perl.  I’m going to put this in a preformatted text block so hopefully WordPress won’t change anything (it doesn’t appear that it has), but you never know.  One final note, don’t confuse backticks (`) with apostrophes (‘) – backticks are used to run a command that would normally be run from a Linux command prompt.

These scripts were written for use with FreePBX 2.11; there are a couple of lines that need to be changed for FreePBX 12 and above which will be posted below the main scripts:

#!/usr/bin/perl

# This program gets the current IP address (as assigned by the ISP) from
# a web page and modifies the FreePBX Asterisk SIP settings if the
# external IP address has changed. Invoke it as cron job that runs every 5 minutes.

use strict;
use warnings;
use WWW::Mechanize;
use Data::Validate::IP qw(is_public_ipv4);

# GET CURRENT IP ADDRESS
my $mech = WWW::Mechanize->new( autocheck => 1 );

# NOTE THE http QUERY IN THE NEXT LINE - PLEASE PASTE THIS INTO YOUR WEB
# BROWSER AND MAKE SURE IT RETURNS YOUR IP ADDRESS AND NOTHING ELSE.
$mech->get('http://some_web_site_that_returns_your_IP_address');
$mech->success or die 'Cannot connect to web site';
my ($ip) = ($mech->content() =~ /(d+.d+.d+.d+)/);

# VALIDATE RESULT RECEIVED

if (is_public_ipv4($ip)) {

	# SET UP TO CONNECT TO MySQL DATABASE
	use DBI();

	# CONNECT TO DATABASE
	my $connect = DBI->connect("DBI:mysql:database=asterisk;host=localhost", "user", "pw", {'RaiseError' => 1});

	# GET IP ADDRESS FROM DATABASE
	my ($externip) = $connect->selectrow_array("SELECT data FROM sipsettings WHERE keyword like ?", undef, "externip_val");

	# COMPARE IP ADDRESSES

	if ($externip ne $ip) {

		# WAIT 5 SECONDS AND RECHECK IP TO AVOID FALSE POSITIVES

		sleep 5;
		$mech->get('http://some_web_site_that_returns_your_IP_address');
		$mech->success or die 'Cannot connect to web site';
		my ($ip) = ($mech->content() =~ /(d+.d+.d+.d+)/);
		if ($externip ne $ip) {

			# IP HAS CHANGED SO UPDATE IP ADDRESS IN DATABASE
			$connect->do("UPDATE sipsettings SET data = ? WHERE keyword = ?", undef, "$ip", "externip_val");

			# WRITE CONFIG FILES AND RELOAD ASTERISK
			`/var/lib/asterisk/bin/module_admin reload`;

			# OPTIONAL SEND EMAIL TO SYSTEM ADMINISTRATOR(S)

			# my $mailstring = 'echo "This is an automated message - please do not reply. Either we had a power or Internet outage (in which case there is a slight chance you may receive this message even if our IP address is unchanged), or our Internet Service Provider has changed the IP address of our phone server to ' . $ip . '" | mail -s "ISP may have changed our IP address" someaddress@gmail.com,anotheraddress@somewhere.com';
			# system($mailstring);
		};
	};
};

Variation (recommended) – note, do NOT confuse backticks and apostrophes, since both are used in this script and they are NOT interchangeable!

#!/usr/bin/perl

# This program gets the current IP address (as assigned by the ISP) from
# OpenDNS and modifies the FreePBX Asterisk SIP settings if the external IP
# address has changed. Invoke it as cron job that runs every 5 minutes.

use strict;
use warnings;
use Data::Validate::IP qw(is_public_ipv4);

my $dig = 'dig +short myip.opendns.com @resolver1.opendns.com';
my $ip=`$dig`;
chomp $ip;
if ($ip=~/((\d){1,3}\.){3}(\d){1,3}/) {
	if (is_public_ipv4($ip)) {

		# SET UP TO CONNECT TO MySQL DATABASE
		use DBI();

		# CONNECT TO DATABASE
		my $connect = DBI->connect("DBI:mysql:database=asterisk;host=localhost", "user", "pw", {'RaiseError' => 1});

		# GET IP ADDRESS FROM DATABASE
		my ($externip) = $connect->selectrow_array("SELECT data FROM sipsettings WHERE keyword like ?", undef, "externip_val");

		# COMPARE IP ADDRESSES

		if ($externip ne $ip) {

			# WAIT 5 SECONDS AND RECHECK IP TO AVOID FALSE POSITIVES

			sleep 5;
			$ip=`$dig`;
			chomp $ip;
			if ($ip=~/((\d){1,3}\.){3}(\d){1,3}/) {
				if (is_public_ipv4($ip)) {
					if ($externip ne $ip) {

						# IP HAS CHANGED SO UPDATE IP ADDRESS IN DATABASE
						$connect->do("UPDATE sipsettings SET data = ? WHERE keyword = ?", undef, "$ip", "externip_val");

						# WRITE CONFIG FILES AND RELOAD ASTERISK
						`/var/lib/asterisk/bin/module_admin reload`;

						# OPTIONAL SEND EMAIL TO SYSTEM ADMINISTRATOR(S)

						# my $mailstring = 'echo "This is an automated message - please do not reply. Either we had a power or Internet outage (in which case there is a slight chance you may receive this message even if our IP address is unchanged), or our Internet Service Provider has changed the IP address of our phone server to ' . $ip . '" | mail -s "ISP may have changed our IP address" someaddress@gmail.com,anotheraddress@somewhere.com';
						# system($mailstring);

					};
				};
			};
		};
	};
};

NOTES on the above scripts, including THINGS YOU MUST CHANGE:

In the first script, change both occurrences of http://some_web_site_that_returns_your_IP_address to a web address that returns only your IP address and nothing else. Enter the link into a web browser to make sure you get the expected result — it should show your external IP address and nothing else. These services tend to come and go, and you’ll need to find one that returns your IP address, and ONLY your IP address, with no extraneous HTML formatting or text. If you don’t know of such a source, then try the second variation.

These rest of this applies to both scripts:

Note the two bolded variables user and pw. These must be changed to the correct values for YOUR system. You will usually find these in one of two places. You can look in /etc/amportal.conf and look for the variables AMPDBUSER and AMPDBPASS — these will usually be near the bottom of the file in newer installs, in a “— CATEGORY: Bootstrapped or Legacy Settings —” section, but they can be anywhere in the file.

Another place they may be found is in the file /etc/freepbx.conf — in that file, look for lines similar to:

$amp_conf[‘AMPDBUSER’] = ‘freepbxuser’;
$amp_conf[‘AMPDBPASS’] = ‘password’;

Those will give you the values to insert into the user and pw variables in the script. YOU MUST INSERT THE CORRECT VALUES OR THE SCRIPT WILL NOT WORK! By the way, if you have both of the above-mentioned files, make sure that the AMPDBUSER and AMPDBPASS variables are set to the same respective values in both files, otherwise your CDR Reports page may not work.

Finally, if you want an e-mail notification when your IP address has changed, uncomment the two lines under “# OPTIONAL SEND EMAIL TO SYSTEM ADMINISTRATOR(S)” and modify the first line appropriately (make sure you use one or more valid e-mail addresses!). BE CAREFUL NOT TO DELETE THE TRAILING APOSTROPHE (just before the semicolon). Yeah, I did that once. 🙁

IF YOUR ARE RUNNING FREEPBX 12 (NOT FreePBX 14, see below), it appears they have changed the location where the IP address is stored in the database. In that case, two sections of the script need to be changed:

Change this:

		# GET IP ADDRESS FROM DATABASE
		my ($externip) = $connect->selectrow_array("SELECT data FROM sipsettings WHERE keyword like ?", undef, "externip_val");

To this:

		# GET IP ADDRESS FROM DATABASE
		my ($externip) = $connect->selectrow_array("SELECT val FROM kvstore WHERE `key` = ?", undef, "externip");

Change this:

						# IP HAS CHANGED SO UPDATE IP ADDRESS IN DATABASE
						$connect->do("UPDATE sipsettings SET data = ? WHERE keyword = ?", undef, "$ip", "externip_val");

To this:

						# IP HAS CHANGED SO UPDATE IP ADDRESS IN DATABASE
						$connect->do("UPDATE kvstore SET val = ? WHERE `key` = ?", undef, "$ip", "externip");

IF YOU ARE RUNNING FREEPBX 14, it appears they have changed the location again where the IP address is stored in the database. In that case, two sections of the script need to be changed:

Change this:

		# GET IP ADDRESS FROM DATABASE
		my ($externip) = $connect->selectrow_array("SELECT data FROM sipsettings WHERE keyword like ?", undef, "externip_val");

To this:

		# GET IP ADDRESS FROM DATABASE
		my ($externip) = $connect->selectrow_array("SELECT val FROM kvstore_Sipsettings WHERE `key` = ?", undef, "externip");

Change this:

						# IP HAS CHANGED SO UPDATE IP ADDRESS IN DATABASE
						$connect->do("UPDATE sipsettings SET data = ? WHERE keyword = ?", undef, "$ip", "externip_val");

To this:

						# IP HAS CHANGED SO UPDATE IP ADDRESS IN DATABASE
						$connect->do("UPDATE kvstore_Sipsettings SET val = ? WHERE `key` = ?", undef, "$ip", "externip");

(Thanks to “Tony” for posing the FreePBX 14 changes in the comment section.)

Regardless of which version you are running (12 or 14), BE CAREFUL, in both of the above lines the word keyword (without quotes) is changed to `key` (with backtick quotes). If you leave out the backticks, or change them to something else such as apostrophes, IT WILL NOT WORK.

Save your script to either the /root directory or the /var/lib/asterisk/agi-bin directory, or to another location of your choosing. I named it checkip.pl, solely because that was the name of a previous script I had run and I had already created a cron job for it. You must make the script executable, for example:

chmod u+rx /var/lib/asterisk/agi-bin/checkip.pl

Of course you will specify the correct filename and directory. Now it’s time to test the script. From the Linux command prompt, navigate to the directory where you stored the script:

cd /var/lib/asterisk/agi-bin

Now run the script from the command prompt:

./checkip.pl

Hopefully you won’t see any error messages. Remember it’s going out to do a query to get your external IP address, so don’t get concerned if it takes a second or two. If you had an incorrect address stored in your FreePBX Asterisk SIP Settings configuration, it will take longer because it will reload the FreePBX configuration. The script has a couple of different checks to make sure it only stores a real IP address (and not something invalid like an error message) in the database, so if it appears to not be working, make sure the underlying call to the web server or the dig command (depending on which variation you use) is returning a valid IP address.

Usually if you do see errors they will fall into one of two categories. The first is a missing Perl module, which you will need to obtain as described above. The second is a syntax error, which you should not get if you cut and pasted the script, and made the changes noted above. If you get a permissions error, you probably forgot to make the script executable!

Setting up a cron job:

Once it runs without errors, you will want to create a cron job so it runs automatically every five minutes. Do NOT run it more often than that, or the lookup service may ban your IP address, and you don’t want that to happen (whatismyip.com would do that, which is another reason not to use them), and besides, it’s not polite to hog the resources of someone else’s server! And if you are running it on multiple servers at the same IP address, then adjust the polling speed so that the total polling from all servers doesn’t exceed once every five minutes. An occasional additional test is probably not an issue, but if you try to poll every minute you just might get banned!

The usual way to add a cron job is to run this command:

crontab -e

(If you’re not currently running as root use sudo crontab -e instead)

This will open a text editor showing your current cron jobs. Just add a new line to the bottom of the file with your new cron job. To run the script every five minutes, you could use something like this:

*/5 * * * * /var/lib/asterisk/agi-bin/checkip.pl

Or to be more specific as to when the script runs (this will run it exactly on the hour, at five minutes after the hour, at ten minutes after the hour, and so on):

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /var/lib/asterisk/agi-bin/checkip.pl

Just save the changed file when you are finished. The alternate method is to use Webmin’s System | Scheduled Cron Jobs module to set up your cron job.

Final testing:

The easiest way to test to make sure this is all working is to wait until a time that there are no active calls on the system, then go to the Asterisk SIP Settings configuration page and change the External IP address to something invalid (just change the last digit of the current address and Submit Changes, then do the usual orange bar reload). On the next five minute interval, the script should detect that the external IP address doesn’t match the one stored in the database, and it will write the correct value to the database and reload Asterisk. If you watch the Asterisk CLI during this time, you should actually see the reload take place. After that, if you go back to the Asterisk SIP Settings configuration page, the correct IP address should be there. To be extra safe, you should also view the contents of the file /etc/asterisk/sip_general_additional.conf and make sure that the externip= line shows the correct IP address.

Now you don’t have to worry about frantic calls from users at inopportune times because your ISP changed your IP address and none of the phones are working, and you also won’t have any of the problems associated with the Dynamic IP method!

I want to thank Moshe Brevda for giving me the information I needed to do the MySQL database write, after a particularly frustrating middle of the night session (not helped by bumping into a truly arrogant bastard on an IRC channel), and also for one correction to this article (see my comment in the comments section below). If any “Perl purists” are reading this and you want to offer a constructive comment without giving me any attitude, I’m fine with that. But if you are like some of your I-know-it-all-and-your-coding-sucks brethren in the IRC channel, don’t even waste your time posting a comment, because I won’t approve it. No, you really DON’T need to use any other Perl database modules to do this simple task, and no, I DON’T want to learn your philosophy of writing Perl code (there are some really sucky mom’s-basement-dwellers inhabiting the IRC channel — some of those folks really need to get professional help, and that is all I will say about that). EDIT: Credit to the article Quickly Get an External IP Address from the Command Line (OS X Daily) for revealing the method of using dig with OpenDNS to get your IP address.

NOTE: As usual, there are no warranties — we’re experimenters here, and sometimes we don’t catch all the bugs, especially on the first go around! However, I would assume that anyone who is running a “professional” installation would pay their ISP for a true static IP address (one that never changes), and therefore wouldn’t need one of these scripts in the first place.