Category: VoIP

Link: Asterisk Hangup Handlers

Overview

Hangup handlers are subroutines attached to a channel that will execute when that channel hangs up. Unlike the traditional h extension, hangup handlers follow the channel. Thus hangup handlers are always run when a channel is hung up, regardless of where in the dialplan a channel is executing.

Multiple hangup handlers can be attached to a single channel. If multiple hangup handlers are attached to a channel, the hangup handlers will be executed in the order of most recently added first.

Full documentation page here:
Hangup Handlers (Asterisk Project)

Note: Hangup handlers were introduced in Asterisk 11, and therefore many long time Asterisk users may not be aware of this new feature. If you have always wanted your Asterisk server to perform some action at the time a call is hung up, a hangup handler might be the solution you have been looking for.

A possible way to thwart SIP hack attempts on your Asterisk (or other) PBX server

If you’ve had the problem of hackers trying to break into your Asterisk server, you probably know that you can use tools like Fail2ban to at least slow them down.  But why let them know you even have an Asterisk server in the first place?  Maybe you need to leave port 5060 open so that remote users (not on your local network) can connect to the server, but that doesn’t mean that you have to advertise to the bad guys that you might have something of interest.  With that in mind, we direct your attention to this post in the DSLReports VoIP forum:

The Linux netfilter/iptables firewall is capable of stopping these attacks before they even start.

At a bare minimum, this stops 99% of the attacks when added to your iptables ruleset:

-A INPUT -p udp --dport 5060 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:your.pbx.dns.name" --algo bm -j ACCEPT
-A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:" --algo bm -j DROP
-A INPUT -p udp --dport 5060 -m string --string "OPTIONS sip:" --algo bm -j DROP
-A INPUT -p udp --dport 5060 -j ACCEPT

Warning
IMPORTANT: Be sure to have a separate iptables rule (higher on the list than those above) that allows connections to port 5060 from devices on your local network. Otherwise, you may find that new extensions that you are adding for the first time will not register with your Asterisk server, or that after a system reboot, none of your local extensions will register!

To understand how this works, read the original post by DSLReports user espaeth.

For another line of defense against such attacks, see the article Stop SOME SipVicious attacks from reaching your Asterisk, FreeSwitch, YATE, etc. PBX server.

Link: Securing Your Asterisk VoIP Server with IPTables

Now that you have set up your personal Asterisk® server, it’s time to secure it. I can’t overstate the importance of this step. Without it, you could be leaving your server’s VoIP and SSH ports open for anyone on the Internet, which is a very bad idea and may cost you a lot of money.

Full article here:
Securing Your Asterisk VoIP Server with IPTables (Lin’s Tech Blog)

Why you can’t get SRTP encryption to work between Asterisk and your VoIP adapter or phone

Some recent versions of Asterisk (Asterisk 11 in particular) have built-in SRTP support of sorts. As Wikipedia notes,

The Secure Real-time Transport Protocol (or SRTP) defines a profile of RTP (Real-time Transport Protocol), intended to provide encryption, message authentication and integrity, and replay protection to the RTP data in both unicast and multicast applications. It was developed by a small team of IP protocol and cryptographic experts from Cisco and Ericsson including David Oran, David McGrew, Mark Baugher, Mats Naslund, Elisabetta Carrara, James Black, Karl Norman, and Rolf Blom. It was first published by the IETF in March 2004 as RFC 3711.

In simple terms, SRTP encrypts the audio of your VoIP calls, making it much more difficult for anyone with a packet sniffer to listen in.

Let’s say you have an Android-based tablet and you are running CSipSimple. If you have configured it as an extension off your Asterisk 11 server, and you turn SRTP on in the security settings, you will likely find that outgoing calls work fine but incoming calls do not.  The reason is that you need to add one line to the extension’s configuration settings in Asterisk:

encryption=yes

If you are using FreePBX then it’s only a bit more complicated.  You’d need to add two lines to the /etc/asterisk/sip_custom_post.conf file:

[####](+)
encryption=yes

Replacing #### with the extension number. Once you have done this and reloaded Asterisk, it will only communicate with the endpoint using SRTP.

BUT there is one problem here.  With some other VoIP devices and softphones, once your have enabled SRTP, any attempt to place an outgoing call will not work.  And, if you watch the Asterisk CLI, you may see lines similar to this:

[2013-12-19 08:18:57] NOTICE[2949][C-000005e9]: sip/sdp_crypto.c:255 sdp_crypto_process: Crypto life time unsupported: crypto:1 AES_CM_128_HMAC_SHA1_80 inline:6aV+PFYMnVJVUZuxug9EM5yefPnfOrNhHcKLSABE|2^20
[2013-12-19 08:18:57] NOTICE[2949][C-000005e9]: sip/sdp_crypto.c:265 sdp_crypto_process: SRTP crypto offer not acceptable
[2013-12-19 08:18:57] WARNING[2949][C-000005e9]: chan_sip.c:10454 process_sdp: Rejecting secure audio stream without encryption details: audio 17100 RTP/SAVP 0 8 18 104 101

The problem is that in Asterisk, “any SRTP offers that specify the optional lifetime key component will fail”, as is detailed in this submitted patch to Asterisk:

(ASTERISK-17899) [patch] Adds a ‘ignorecryptolifetime’ (Ignore Crypto Lifetime) option to sip.conf for SRTP keys specifying optional ‘lifetime’

If if the device or softphone had a setting to disable sending the lifetime parameter, it probably would work. If users would go through the trouble of applying this patch to Asterisk, it would probably work, but many users either don’t know how to do that, or they are running a pre-built distribution and don’t want to or cannot tamper with it (also, any upgrades to Asterisk thereafter would require re-application of the patch). If Digium would apply this patch to Asterisk and push it out in upgrade releases, it probably would work. But for whatever reason, though this patch was first posted back in May of 2011, Digium has not seen fit to roll it into Asterisk.

So, this may very well be the reason, or at least one of the reasons, why you can’t get SRTP encryption to work between Asterisk and your VoIP adapter or phone! Basically, your VoIP device or softphone and Asterisk just don’t want to play nice with each other.

We’ve heard that some other varieties of PBX software, such as FreeSWITCH, might not have this issue, but since we don’t have a working FreeSWITCH installation at the moment we cannot comment on that.

Link: Improving Asterisk call quality with SIP jitter buffers

I had a customer let me know that they had improved their call quality from WiFi and 3G connections by turning on the Asterisk jitter buffers for SIP connections. If you have any extensions where connection quality is intermittent it could be worth trying.

Full article here:
Improving Asterisk call quality with SIP jitter buffers (SysAdminMan Blog)

Note that the article mentions that “This can by done with the FreePBX SIP Settings module”, but does not mention the settings when using that method. Although they should be fairly obvious, we’ll mention them anyway:

Under Settings / Asterisk SIP Settings in the Jitter Buffer Settings section:
Jitter Buffer: Enabled
Force Jitter Buffer: No
Implementation: Adaptive
Jitter Buffer Logging: Disable
Jitter Buffer Size: 200 (jbmaxsize) 1000 (jbresyncthreshold)

The two items in bold text correspond to the ones discussed in the above-mentioned article.

How to hack the FreePBX blacklist for better call blocking capability

NOTE:  There is a newer version of this article that adds TrueCNAM scoring to help weed out telemarketers, robo-callers, and other “spam” callers.  See How to hack the FreePBX blacklist for better call blocking capability, take 2 – adding TrueCNAM scoring for that article, or continue here if you don’t want to use TrueCNAM scoring.

Have you ever wished that you could blacklist calls in FreePBX using criteria other than just the exact phone number?  It’s quite possible, and here’s an explanation of how it can be accomplished.

First, using a text editor such as nano, go into the file /etc/asterisk/extensions_additional.conf and find the context headed [app-blacklist-check]. It will probably look like this:

[app-blacklist-check]
include => app-blacklist-check-custom
exten => s,1(check),GotoIf($[“${BLACKLIST()}”=”1”]?blacklisted)
exten => s,n,Set(CALLED_BLACKLIST=1)
exten => s,n,Return()
exten => s,n(blacklisted),Answer
exten => s,n,Wait(1)
exten => s,n,Zapateller()
exten => s,n,Playback(ss-noservice)
exten => s,n,Hangup

Note that this is a pretty simple macro context. The first line checks to see if a caller ID number appears in the Asterisk blacklist, and if so, it shuffles the call off to a “number not in service” recording.

If you copy and paste this entire context into the file /etc/asterisk/extensions_override_freepbx.conf and remove the “include” line at the start of the macro, you can then modify it to do what you want. Let’s look at that same context again, but with a few added lines, as it might appear in /etc/asterisk/extensions_override_freepbx.conf

[app-blacklist-check]

;Make sure CDR DID field is set on blacklisted calls
exten => s,1(check),Set(CDR(did)=${FROM_DID})
;Original first line of context with line number changed
exten => s,n,GotoIf($[“${BLACKLIST()}”=”1”]?blacklisted)
;Blacklist Caller ID names found in custom Asterisk database blistname if used
exten => s,n,GotoIf($[“${DB_EXISTS(blistname/${TOUPPER(${CALLERID(name)})})}”=”1”]?blacklisted)
;Blacklist Caller ID names of single letter followed by 9 or more digits
exten => s,n,Set(regx=^[A-Z][0-9]{9}[0-9]* *$)
exten => s,n,GotoIf($[${REGEX(“${regx}” ${CALLERID(name)})} = 1]?blacklisted)
;Blacklist numbers where first digit of 7 digit local number is 0 or 1
exten => s,n,Set(regx=^[+]?1?[0-9]{3}[01][0-9]{6}$)
exten => s,n,GotoIf($[${REGEX(“${regx}” ${CALLERID(num)})} = 1]?blacklisted)
;Blacklist numbers where first digit of area code is 0 or 1
exten => s,n,Set(regx=^[+]?1?[01][0-9]{9}$)
exten => s,n,GotoIf($[${REGEX(“${regx}” ${CALLERID(num)})} = 1]?blacklisted)
;Blacklist numbers where first three digits of 7 digit local number are 555
exten => s,n,Set(regx=^[+]?1?[0-9]{3}555[0-9]{4}$)
exten => s,n,GotoIf($[${REGEX(“${regx}” ${CALLERID(num)})} = 1]?blacklisted)
;Blacklist numbers that start with 1 but are longer than 11 digits total
exten => s,n,Set(regx=^[+]?1[0-9]{11}[0-9]*$)
exten => s,n,GotoIf($[${REGEX(“${regx}” ${CALLERID(num)})} = 1]?blacklisted)
;Blacklist numbers of less than 7 digits in length
exten => s,n,GotoIf($[${LEN(${CALLERID(num)})} < 7]?blacklisted)
;Blacklist numbers of 8 digits in length
exten => s,n,GotoIf($[${LEN(${CALLERID(num)})} = 8]?blacklisted)
;Next line is from the original blacklist context
exten => s,n,Set(CALLED_BLACKLIST=1)
;Special CallerID name lookup; should not really be here but works
exten => s,n,ExecIf($[“${DB_EXISTS(cidname/${CALLERID(num)})}”!=”1″]?Return())
exten => s,n,Set(CALLERID(name)=${DB(cidname/${CALLERID(num)})})
exten => s,n,Set(__SKIPCIDLOOKUP=1)
;More original blacklist context
exten => s,n,Return()
exten => s,n(blacklisted),Answer
;Prepend *BL* to Caller ID name of blacklisted numbers so they can be distinguished in CDR
exten => s,n,Set(CALLERID(name)=*BL*${CALLERID(name)})
;Set Call Detail Record Userfield to Blacklisted
exten => s,n,Set(CDR(userfield)=Blacklisted)
;Still more original blacklist context
exten => s,n,Wait(1)
exten => s,n,Zapateller()
exten => s,n,Playback(ss-noservice)
exten => s,n,Hangup

;–== end of [app-blacklist-check] ==–;

The lines in blue are from the original context that was copied from /etc/asterisk/extensions_additional.conf.  We should mention here that not all the ideas in the new lines are original with us; some are adaptations of things we’ve read over many months in various forums.

You don’t need to use all of these added lines shown.  On the other hand, you can add your own customizations.  Here is what each added line (or set of lines) means:

The change to line 1 (moving the original line 1 down to the next line) adds Set(CDR(did)=${FROM_DID}), which causes the call detail record to show the DID the call came in on for blacklisted calls.

;Blacklist Caller ID names found in custom Asterisk database blistname if used
exten => s,n,GotoIf($[“${DB_EXISTS(blistname/${TOUPPER(${CALLERID(name)})})}”=”1”]?blacklisted)

This addition allows you to blacklist by exact Caller ID name.  To add a name to the blacklist-by-name database, go into the Asterisk CLI and enter this:

database put blistname NAME 1

Where NAME is the name you want to add – enclose it in quotation marks if it contains spaces:

database put blistname “SOME NAME” 1

You can use a descriptive word if you like in place of the number 1 at the end of the line.  To delete an already entered name:

database del blistname NAME

And to see what’s already in the blacklist-by-name database:

database show blistname

Next we come to:

;Blacklist Caller ID names of single letter followed by 9 or more digits
exten => s,n,Set(regx=^[A-Z][0-9]{9}[0-9]* *$)
exten => s,n,GotoIf($[${REGEX(“${regx}” ${CALLERID(name)})} = 1]?blacklisted)

These lines are an example of blacklisting a Caller ID name using a regular expression. This will catch any Caller ID name that starts with a single letter and is followed by 9 or more digits, and any number of spaces at the end.  This particular example will get rid of those irritating Vnnnnnnnnn… name calls, even if they change the starting letter to something other than “V”.

;Blacklist numbers where first digit of 7 digit local number is 0 or 1
exten => s,n,Set(regx=^[+]?1?[0-9]{3}[01][0-9]{6}$)
exten => s,n,GotoIf($[${REGEX(“${regx}” ${CALLERID(num)})} = 1]?blacklisted)

;Blacklist numbers where first digit of area code is 0 or 1
exten => s,n,Set(regx=^[+]?1?[01][0-9]{9}$)
exten => s,n,GotoIf($[${REGEX(“${regx}” ${CALLERID(num)})} = 1]?blacklisted)

;Blacklist numbers where first three digits of 7 digit local number are 555
exten => s,n,Set(regx=^[+]?1?[0-9]{3}555[0-9]{4}$)
exten => s,n,GotoIf($[${REGEX(“${regx}” ${CALLERID(num)})} = 1]?blacklisted)

These are three examples of blacklisting numbers by regular expression patterns.  The first example blacklists numbers that have an invalid exchange (where the 7-digit part of the number starts with 0 or 1), while the second blacklists numbers that come in with an area code starting with 0 or 1, which is invalid.  The third blocks numbers that appear to come from the “directory assistance” exchange 555 in any area code. In all cases, it does not matter if the number starts with a leading + and/or 1.  Note that Asterisk has a fairly restrictive syntax for regular expressions, so you can’t do many of the substitutions that would be possible in other computer languages. See the article, Did you know that Asterisk has the ability to evaluate Regular Expressions, though not in the same way as Perl or FreeSWITCH? for more information.

You can always add additional blacklist patterns by duplicating an appropriate pair of lines (for blacklisting by name or number pattern) and then modifying the regular expression.  For example, to block calls from certain specific area codes, you could use a regular expression of the form ^[+]?1?(xxx|yyy|zzz)[0-9]{7}$ where xxx, yyy, and zzz are the area codes you want to block.  You can include as many area codes as you need, separated by the | character.

;Blacklist numbers of 8 digits in length
exten => s,n,GotoIf($[${LEN(${CALLERID(num)})} = 8]?blacklisted)

This is an example of blocking numbers of a specific length.  If you have a bad caller that sends numbers that are exactly 8 characters in length, this will catch them. You can, of course, change the “8” to catch other bad length numbers, but be careful not to inadvertently block wanted international or other valid calls with non-standard number lengths.

The next added section consists of these lines:

;Special CallerID name lookup; should not really be here but works
exten => s,n,ExecIf($[“${DB_EXISTS(cidname/${CALLERID(num)})}”!=”1″]?Return())
exten => s,n,Set(CALLERID(name)=${DB(cidname/${CALLERID(num)})})
exten => s,n,Set(__SKIPCIDLOOKUP=1)

It could be argued that this doesn’t really belong in the blacklist code, so feel free to omit it if you don’t like it – remember, these are just examples.  What this does is checks the Asterisk Phonebook to see if the calling number appears there, and if it does, it sets the Caller ID name to the name associated with that number in the Phonebook.  There are other ways to do this, but we show it here for one simple reason – you could use it to “whitelist” a certain number that would otherwise be taken out by a regular expression-based rule, although you’d have to modify the dialplan shown here a bit to do so.  As it stands, this only does the Asterisk Phonebook lookup, and applies the name from the Asterisk Phonebook if it finds it there.

There is one issue with doing this, and that is that if you use another Caller ID lookup source it will override the Asterisk Phonebook lookup.  To avoid that, you can copy the [cidlookup] context from /etc/asterisk/extensions_additional.conf to /etc/asterisk/extensions_override_freepbx.conf and change the first line to a test for the SKIPCIDLOOKUP variable.  For example, if the first line is:

exten => cidlookup_1,1,Set(CURLOPT(httptimeout)=7)

You could change it to:

exten => cidlookup_1,1,ExecIf($[“${SKIPCIDLOOKUP}”=”1”]?Return())
exten => cidlookup_1,n,Set(CURLOPT(httptimeout)=7)

Don’t forget to change the line number 1 to n in the original first line, since it’s no longer line 1.

Finally, the last hack shown is this – you would probably want to use one or the other of these, but not both:

;Prepend *BL* to Caller ID name of blacklisted numbers so they can be distinguished in CDR
exten => s,n,Set(CALLERID(name)=*BL*${CALLERID(name)})

;Set Call Detail Record Userfield to Blacklisted
exten => s,n,Set(CDR(userfield)=Blacklisted)

We don’t recall where we first saw this, but it is a great idea.  In the first example, if the call is blacklisted, the characters *BL* are added to the start of the Caller ID name, and appear that way in the call detail. In the second example, the “Userfield” in the call detail record is set to the word “Blacklisted”.  Whichever you use, when you are looking at your call records, this tells you instantly if a problem caller is already being blacklisted, so you don’t need to wonder if you should add them to the blacklist.  The first example is probably more appropriate for older FreePBX systems that didn’t display the Userfield in the call detail, while the second works much better in newer FreePBX installations.  I would not suggest using both, though there is no harm if you do.

Keep in mind that any time you replace a context in /etc/asterisk/extensions_override_freepbx.conf, it is your responsibility to make sure it “tracks” any changes to the original context in /etc/asterisk/extensions_additional.conf.  So, after any major FreePBX upgrade, you should take a look at the original [app-blacklist-check] context (and the [cidlookup] context, if you have modified that) and make sure that they have not changed, and if they have, that you make the same changes to your replacement contexts.

One additional point – at the top of each of the original contexts, there is an “include” statement that we suggest you remove when you copy the context to /etc/asterisk/extensions_override_freepbx.conf, for example, “include => app-blacklist-check-custom“.  You might wonder if you could create a context named app-blacklist-check-custom in /etc/asterisk/extensions_custom.conf and copy the original context there.  But, for whatever reason, that just doesn’t seem to work, and there’s no real advantage to putting the copied context there anyway.

EDIT: If the above seems too complicated, there is an alternate technique that may work for some FreePBX users, provided you don’t care about receiving international calls.  See this thread on DSLReports for details.

Related articles:
Link: Asterisk: Blacklisting For Multiple Users
Forum thread: User-specific Caller ID/whitelist/blacklist in Asterisk/FreePBX

Link: Asterisk: Blacklisting For Multiple Users

Spotted this article referenced in a thread on DSLReports.com, and even though it’s from four years ago we thought it might be worth mentioning:

There are a number of tutorials for people trying to setup blacklisting for their Asterisk server, but they all seem to assume that there is only one user on the server, or at least all users want to share the same blacklist.

Since I host for multiple, unrelated people, they don’t necessarily want to share the same blacklist, so I had to come up with a configuration that would work for all customers.

Here are the changes I made (for Asterisk 1.4)

This may or may not need to be tweaked a bit to work with newer versions of Asterisk. Unfortunately, the thread on DSLReports leaves the impression that it might take a bit of work to integrate it into FreePBX, so you are on your own if you want to attempt that.

Full article here:
Asterisk: Blacklisting For Multiple Users (Lime Daley)
Related Link:
How to hack the FreePBX blacklist for better call blocking capability

Not such a great deal on a VoIP PBX?

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

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

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

Asterisk on a Raspberry Pi – which distribution is best?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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