Category Archives: FreeSwitch

Stop SOME SipVicious attacks from reaching your Asterisk, FreeSwitch, YATE, etc. PBX server

This tip was posted by user “infotek” on the FreePBX site but applies to all software PBX systems that use the iptables firewall. “infotek” wrote:

By default the SipVicious scanner uses the ua : “friendly-scanner”. To block this ua, you can have iptables search the packet for that text.

add the following line to /etc/sysconfig/iptables

-A INPUT -p udp -m udp –dport 5060 -m string –string “friendly-scanner” –algo bm –to 500 -j DROP

Now the thing to keep in mind about this is that it only works if you know the string that will be sent as the user agent, and some hackers using SipVicious may take the trouble to change that default string, but some protection is better than none.  However this same technique can be used to block any attack that constantly sends the same string as the user agent, if you know what that string contains.

For those that use Webmin to manage iptables, here are the settings to use.  This should come BEFORE any other rules applicable to port 5060 – I made it the very first rule on the page “Incoming packets (INPUT) – Only applies to packets addressed to this host“:

Rule comment: Stop SipVicious
Action to take: Drop
Network protocol: Equals UDP
Destination TCP or UDP port: Equals Port(s) 5060
Additional IPtables modules: string
Additional parameters: –string “friendly-scanner” –algo bm –to 500

All other settings on the Webmin “Add Rule” page should be left at the default value (usually <ignored>).

To stop the hackers clever enough to change the default user agent string, consider also using this technique.

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

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

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

Step 1:

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

SIP Port Forwarding 1

Step 2:

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

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

SIP Port Forwarding 2

Step 3:

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

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

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

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

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

If you used the information from the article, “A possible way to thwart SIP hack attempts on your Asterisk (or other) PBX server”, please read this

If you took the advice in the article, A possible way to thwart SIP hack attempts on your Asterisk (or other) PBX server, please be aware that an important note has been added:

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!

Please take heed of that note, or you may be one power failure or reboot away from discovering that none of your local extensions are able to register with your PBX server.

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![/warning]

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.

Asterisk on a Raspberry Pi – which distribution is best?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Not receiving some incoming Google Voice calls? Try increasing the priority

A page on the Asterisk Wiki entitled Calling using Google contains this bit of information about priorities:

More about Priorities

As many different connections to Google are possible simultaneously via different client mechanisms, it is important to understand the role of priorities in the routing of inbound calls. Proper usage of the priority setting can allow use of a Google account that is not otherwise entirely dedicated to voice services.

With priorities, the higher the setting value, the more any client using that value is preferred as a destination for inbound calls, in deference to any other client with a lower priority value. Known values of commonly used clients include the Gmail chat client, which maintains a priority of 20, and the Windows GTalk client, which uses a priority of 24. The maximum allowable value is 127. Thus, setting one’s priority option for the XMPP peer in res_xmpp.conf to a value higher than 24 will cause inbound calls to flow to Asterisk, even while one is logged into either Gmail or the Windows GTalk client.

Outbound calls are unaffected by the priority setting.

Therefore, if you are not receiving some incoming Google Voice calls, check to make sure that your priority= statement in the configuration is set to at least 25.

Read more: Calling using Google

Yes, you can run FusionPBX and FreeSWITCH on a Raspberry Pi

 

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.

By now most technically inclined folks have heard of the Raspberry Pi, the small $35 computer that can do big things. If you are going to buy one, just make sure you get one of the newer models with 512 MB of memory, rather than an older model with only 256 MB.

But, you may wonder, can I run a decent PBX system (one that won’t get in my way and treat me like a blithering idiot while I’m attempting to configure it) on a computer this small? Well, it turns out that people are doing just that:

The following guide is a relatively easy way to install FusionPBX and FreeSWITCH with the Ubuntu/Debian script.

Raspberry Pi Script (FusionPBX Wiki)

EDIT April, 2017: For a newer method see this DSLReports thread.

It should be obvious that you’ll probably find this easier if you know a bit about the Raspberry Pi first (Google it) but if you want a reliable and configurable PBX, and you think you have the skills to follow these instructions and make it work, I’d definitely give it a try. Besides, for home users, it’s a lot easier to justify a separate computer just to handle your phone calls if it’s small, cheap, and unobtrusive, and has low power consumption.

Using YATE to overcome Google Voice issues in FreeSWITCH and Asterisk

 

Notice
(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. The information in this article is VERY outdated and probably will not work.

 

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.

If you have been less than thrilled with the Google Voice support in another software PBX, such as Asterisk or FreeSWITCH, you could try using YATE as a Google Voice Gateway.  It can be installed on either a separate server, or on the same server as your FreeSWITCH or Asterisk installation, however if you are running virtual machines then I recommend the separate server approach.  In fact, that may be the only way to do it with FreeSWITCH if you installed FreeSWITCH under Debian or Ubuntu, since the YATE install requires CentOS.  If you are a Linux expert you may be able to get around this, but don’t ask me how.

To install YATE, see this article from Nerd Vittles:

YATE in a Flash: Rolling Your Own SIP to Google Voice Gateway for Asterisk

EDIT: You may want to upgrade YATE to the latest version.

Just follow the instructions there, and the ones that you see after running the script to add a Google Voice user, and you should be fine, if you are using Asterisk.  The only things I would suggest that are not shown in those instructions are that you set your Trunk “Maximum Channels” to 2, because a Google Voice account will only permit two simultaneous channels of usage maximum, and that if YATE is on a separate server with a static IP address then I’d suggest adding permit/deny lines to the Asterisk Trunk PEER details to enhance security, like so:

permit=xx.xx.xx.xx/255.255.255.255
deny=0.0.0.0/0.0.0.0

Make sure the lines appear in that order, and replace xx.xx.xx.xx with the static IP address of the YATE server.  This may not help much because Asterisk is registering with the YATE server, but it can’t hurt either.

Also, you might want to consider changing the context statement to

context=from-pstn-e164-us

to remove the +1 from the start of the Caller ID number on incoming calls.

The instructions don’t tell you to add a Dialed Number Manipulation Rule to your trunk configuration, but if you want to allow ten digit calls from any of your endpoints then you should add one rule that prepends 1 to 10 digit calls:

1+NXXNXXXXXX (The 1 goes in the first field, the NXXNXXXXXX in the third field)

If you are using the CallerID Superfecta module, and you use “Trunk Provided” as one of your data source, then after adding a Google Voice account to YATE I suggest editing /usr/local/etc/yate/regexroute.conf on the YATE server. You may need to install an editor first. For example, to install nano and then edit the file:

yum install nano
nano /usr/local/etc/yate/regexroute.conf

Look for the [contexts] section and there you will see a line for each of your Google Voice accounts that looks like this:

${in_line}GV1234567890=;called=GV1234567890;jingle_version=0;jingle_flags=noping;dtmfmethod=rfc2833

Just add ;callername to the end of each such line:

${in_line}GV1234567890=;called=GV1234567890;jingle_version=0;jingle_flags=noping;dtmfmethod=rfc2833;callername

This will make sure that nothing is sent for a Caller ID name, so that Caller ID Superfecta will recognize that there is no “Trunk Provided” name and attempt to do a name lookup (note that you could also use ;callername=something to set the Caller ID name to a specific value). If you want to have ;callername
automatically appended whenever you create a new account, just use an editor to edit the script you use to add users, and find the line that looks like this (it should be near the bottom of the script):

${in_line}GV’$acctphone’=;called=GV’$acctphone’;jingle_version=0;jingle_flags=noping;dtmfmethod=rfc2833

Add ;callername to the end of the line, like so:

${in_line}GV’$acctphone’=;called=GV’$acctphone’;jingle_version=0;jingle_flags=noping;dtmfmethod=rfc2833;callername

Save the modified file, and any time you add a new user it will automatically write that line with ;callername appended.

Thanks to Bill Simon for telling me about this method of sending the blank Caller ID name. Alternately, if you don’t want to mess with the YATE configuration, you could add a new Caller ID Scheme in Caller ID Superfecta that is only used with your Google Voice DID’s and that doesn’t include “Trunk Provided” as a data source.

Whether you are connecting from Asterisk or FreeSWITCH, if YATE is running on a separate server and the other system can’t register with YATE, it may be a firewall issue on the YATE server.  After I did the install I found that iptables was configured to only allow incoming ssh connections.  I modified that rule to only allow incoming ssh from a particular IP address (the one I’d be coming in from) and then added rules to permit traffic from the two servers allowed to talk to that YATE server.

EDIT: Hopefully this will not affect you if you have upgraded YATE to the latest version, but if you have a moderate number of Google Voice accounts, you may experience another issue.  If you start seeing messages like this when you telnet to YATE and then use debug on to see what is happening:

<sip:MILD> Flood detected: 20 handled events

And if every so often, the server appears to go into a semi-catatonic state, where calls come in but they don’t go out (this happened to me at least twice before I figured out what was happening), then you may have this issue.  It occurs when you have the same Asterisk server using multiple trunks to connect to YATE.  It turns out that whenever you reload Asterisk (as you might after making a configuration change, for example the “orange bar reload” in one particular GUI), it resends all of the registrations at once, and gives them all a default timeout of 120 seconds, so they all attempt to re-register at the exact same intervals.  And if you have several trunks, there are a LOT of SIP packets sent.  Plus, with qualifyfreq value set to 240, that means that every other time the registrations are taking place, qualifies are also taking place at the same time.  It appears that this is sufficient to cause that warning to appear once in a while.

The method I found that seems to fix this may not be the best way (feel free to comment if you know a better way), but it’s one way to deal with it.  What you need to do is change the registration expiration on each individual trunk so they are not all the same.  In Asterisk this can be accomplished by adding both of these settings to the trunk configuration (susbtitute nn with some random number of seconds, say between 90 and 120, and make it the same for both settings in each trunk, but different for different trunks)

In the trunk PEER details, add:

defaultexpiry=nn

In the Register String, add  ~nn  to the end of the line, replacing nn with the same value used in the defaultexpiry setting, like so:
GV1234567890:password@exampleaddress.com:5060/1234567890~nn

You might also need to vary the qualifyfreq value a bit in each trunk, so that it’s a bit under the specified 240 seconds and different for each trunk.  If doing those things doesn’t fix the issue, and you still get the <sip:MILD> Flood detected: 20 handled events message frequently, that could mean you are being subjected to an actual SIP attack.  The YATE installation includes a script with the filename /usr/src/yate/share/scripts/banbrutes.php that can be used to deal with that issue, but it’s not enabled by default.  View the banbrutes.php script in a text editor, and you’ll find instructions at the beginning of the script.  Or, you could tighten up the iptables firewall to only allow traffic from systems that are supposed to be talking to your YATE server.

END OF EDIT.

As for FusionPBX, when you create a new Google Voice account on the YATE server using the provided add-yate-user script, at the end it will give you a bunch of configuration information for Asterisk.  These translate to FusionPBX Gateway settings as follows (showing what the script prints and the equivalent FusionPBX Gateway settings):

Trunk Name: YIAF1 ; or increment 1 if more than one (in FusionPBX I suggest you don’t use this; instead use the same setting as the Username for the Gateway name, particularly if you plan on having more than one Google Voice account)

host=x.x.x.x (Proxy in FusionPBX)
username=GV1234567890 (Username in FusionPBX)
secret=password (Password in FusionPBX)
type=peer (Not needed in FusionPBX)
port=5060 (Not needed in FusionPBX)
qualify=yes (Not needed in FusionPBX)
qualifyfreq=240 (Not needed in FusionPBX)
insecure=port,invite (Not needed in FusionPBX)
context=from-trunk (Not needed in FusionPBX)

Register String: … (Not needed in FusionPBX)

In FusionPBX, set Register to True and Enabled to True, and leave other Gateway settings at the defaults (EDIT: however, if you have several gateways to YATE, you might want to use the Expire seconds setting in FusionPBX to vary the registration timeouts a bit so that all your accounts aren’t trying to re-register at exactly the same time — see the longer EDIT section above for details).  Note that after you save the settings, it may take a few seconds for the state to change to REGED, so refresh the Gateways page after a bit and it should be okay if everything is configured properly and there are no firewall issues.

For your Inbound Route in FusionPBX, just use the Trunk Name/Username as the Destination Number (including the leading “GV“, which you can also use it in the Inbound Route name field if you like) and then choose the appropriate Action. When you first create the Inbound Route it will complain if you try to save a Destination Number that is not completely numeric, so just use any number and save the settings, then go back and edit the Destination Number field and also the Data field for the destination_number condition (which should be something like ^GV1234567890$, substituting your Google Voice number for the digits, of course).

For your Outbound Route, select your Google Voice trunk as the Gateway, and then select “11 digits long distance” from the dropdown in the “Dialplan Expression” setting. Save that, and if you only have one Google Voice trunk for all users on the system, that is all you need to do.  However, if you want to have multiple Google Voice trunks and have certain extensions only have access to certain trunks, the edit the Outbound Route you just created, and in the “Conditions and Actions” section at the bottom of the page, edit the last action on the page (the “bridge” action).  You want to change the Data field – it will contain something like sofia/gateway/GV1234567890/$1 and you want to change that to sofia/gateway/${accountcode}/$1 — save that change, and then when the Outbound Route page reappears, you may want to change the name to ${accountcode}.11d and add a Description like “Google Voice: Extension Account Code = Gateway Name” so you understand what the route is doing.  This single Outbound Route will handle all your Google Voice calls from all your extensions, if the Account Code setting for each Extension is set to the name of the Gateway for the Google Voice account you want that extension to use.

Note that if you are running PBX in a Flash, you can use the “Caller ID Superfecta” module to try to get a Caller ID name.  IF YATE itself has any ability to do Caller ID name lookups, someone will have to tell me how to enable and configure it, because at this point I would have no clue.  If you know, please leave a comment!

EDIT: To keep the YATE log file from growing too large over time, copy the file /usr/src/yate/packing/yate.logrotate into /etc/logrotate.d as “yate” (get rid of the .logrotate extension).  That file instructs the system logrotate job to roll the yate log file when it gets to 100 MB.  Thanks to Bill Simon for that tip!

EDIT 2: If you have ignored the advice given almost everywhere to create a new, separate Gmail account, and then use that account when you create your Google Voice account, then you have probably run into the issue of not receiving your incoming calls when you are logged into that Google account and for some time thereafter.  That problem, and one possible fix (along with the drawbacks) were discussed in a post in the thread “YATE in a Flash 1.2 Ready” on the PBX in a Flash Forum, which unfortunately disappeared from that site due to a server crash.  The post, originally by user Marian on Aug 6, 2012, read as follows:

Gmail sets a greater resource priority when you connect and don’t advertise unavailable for a while after you disconnect.
So, if you connect to GMail using the same account as yate the calls will be sent there until GMail advertise resource unavailable.
You can set priority=10 in accfile.conf, gmail account section.
But, if you do that you might not see your chat in GMail or another jabber client connected to GMail for the same account (like GTalk or Yate Client).
Unfortunately, the jabber protocol don’t allow setting different priorities for the same resource for different services (e.g. you can’t set a priority for chat and another one for another capatibility, like jingle calls).
I didn’t found a workaround for this situation: having, for the same account, a resource for chat and another one for jingle calls.
This would require a custom jabber client or a custom jabber server.

That, coupled with information from other posts around the web, means the best advice is to add a line of the form:

priority=127

in each of your Google Voice accounts in the file accfile.conf (in the /usr/local/etc/yate directory).

If you want that line to be added by default when you add a new Google Voice account to your YATE server, open the add-yate-user script (which is probably in your /root directory) in a text editor such as nano, and find this line:

echo “options=allowplainauth” >> accfile.conf

and underneath it add this:

echo “priority=127″ >> accfile.conf

Then save the edited file.  I make no guarantees that this will actually work, but it’s worth a try. NOTE: The thread mentioned above suggested setting the priority to 10, however, the Asterisk developers are now using 25. As this wiki page explains:

More about Priorities

As many different connections to Google are possible simultaneously via different client mechanisms, it is important to understand the role of priorities in the routing of inbound calls. Proper usage of the priority setting can allow use of a Google account that is not otherwise entirely dedicated to voice services.

With priorities, the higher the setting value, the more any client using that value is preferred as a destination for inbound calls, in deference to any other client with a lower priority value. Known values of commonly used clients include the Gmail chat client, which maintains a priority of 20, and the Windows GTalk client, which uses a priority of 24. The maximum allowable value is 127. Thus, setting one’s priority option for the XMPP peer in res_xmpp.conf to a value higher than 24 will cause inbound calls to flow to Asterisk, even while one is logged into either Gmail or the Windows GTalk client.

Outbound calls are unaffected by the priority setting.

This would be true in Asterisk OR YATE, therefore the recommendation is to now use at least 25 as the priority value, up to the maximum of 127 as suggested above.

Two things I wish you could do in Asterisk or FreePBX, or ANY free software PBX

 

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.

I want to explain a problem that apparently exists in current implementations of Asterisk and FreePBX (and by extension, all distributions based on those pieces of software).

Let’s say you have several extensions on your system and many, if not all of them, have a specific “trunk” associated with that extension.  It may be a provider account or a Google Voice account that’s used exclusively by that extension.  Routing INCOMING calls is usually not difficult at all, you simply use the trunk’s DID in an Inbound Route and then route the calls from that DID directly to the desired extension.  However, OUTBOUND is another matter.  You have to create an Outbound Route, and in that route you have to put your dial patterns and use the /extension suffix. It can still be difficult to set up the dial patterns the way you need them.  In 2.8 and later it is much harder because of the individual boxes for each segment of each pattern.

Let’s say you want certain extensions to only be able to call numbers in U.S. area codes, but each of those extensions has its own trunk. And let’s say your extensions are numbered 1000 through 1099. Oh, and you want to support both 10 and 11 digit dialing. So in your outbound route for extension 1000, you might have a list of patterns like this (please scroll down to the end of this long list — it’s only about 600 lines!):

1201NXXXXXX/1000
1202NXXXXXX/1000
1203NXXXXXX/1000
1205NXXXXXX/1000
1206NXXXXXX/1000
1207NXXXXXX/1000
1208NXXXXXX/1000
1209NXXXXXX/1000
1210NXXXXXX/1000
1212NXXXXXX/1000
1213NXXXXXX/1000
1214NXXXXXX/1000
1215NXXXXXX/1000
1216NXXXXXX/1000
1217NXXXXXX/1000
1218NXXXXXX/1000
1219NXXXXXX/1000
1224NXXXXXX/1000
1225NXXXXXX/1000
1228NXXXXXX/1000
1229NXXXXXX/1000
1231NXXXXXX/1000
1234NXXXXXX/1000
1239NXXXXXX/1000
1240NXXXXXX/1000
1248NXXXXXX/1000
1251NXXXXXX/1000
1252NXXXXXX/1000
1253NXXXXXX/1000
1254NXXXXXX/1000
1256NXXXXXX/1000
1260NXXXXXX/1000
1262NXXXXXX/1000
1267NXXXXXX/1000
1269NXXXXXX/1000
1270NXXXXXX/1000
1274NXXXXXX/1000
1276NXXXXXX/1000
1281NXXXXXX/1000
1301NXXXXXX/1000
1302NXXXXXX/1000
1303NXXXXXX/1000
1304NXXXXXX/1000
1305NXXXXXX/1000
1307NXXXXXX/1000
1308NXXXXXX/1000
1309NXXXXXX/1000
1310NXXXXXX/1000
1312NXXXXXX/1000
1313NXXXXXX/1000
1314NXXXXXX/1000
1315NXXXXXX/1000
1316NXXXXXX/1000
1317NXXXXXX/1000
1318NXXXXXX/1000
1319NXXXXXX/1000
1320NXXXXXX/1000
1321NXXXXXX/1000
1323NXXXXXX/1000
1325NXXXXXX/1000
1327NXXXXXX/1000
1330NXXXXXX/1000
1331NXXXXXX/1000
1334NXXXXXX/1000
1336NXXXXXX/1000
1337NXXXXXX/1000
1339NXXXXXX/1000
1347NXXXXXX/1000
1351NXXXXXX/1000
1352NXXXXXX/1000
1360NXXXXXX/1000
1361NXXXXXX/1000
1364NXXXXXX/1000
1385NXXXXXX/1000
1386NXXXXXX/1000
1401NXXXXXX/1000
1402NXXXXXX/1000
1404NXXXXXX/1000
1405NXXXXXX/1000
1406NXXXXXX/1000
1407NXXXXXX/1000
1408NXXXXXX/1000
1409NXXXXXX/1000
1410NXXXXXX/1000
1412NXXXXXX/1000
1413NXXXXXX/1000
1414NXXXXXX/1000
1415NXXXXXX/1000
1417NXXXXXX/1000
1419NXXXXXX/1000
1423NXXXXXX/1000
1424NXXXXXX/1000
1425NXXXXXX/1000
1430NXXXXXX/1000
1432NXXXXXX/1000
1434NXXXXXX/1000
1435NXXXXXX/1000
1440NXXXXXX/1000
1442NXXXXXX/1000
1443NXXXXXX/1000
1458NXXXXXX/1000
1469NXXXXXX/1000
1470NXXXXXX/1000
1475NXXXXXX/1000
1478NXXXXXX/1000
1479NXXXXXX/1000
1480NXXXXXX/1000
1484NXXXXXX/1000
1501NXXXXXX/1000
1502NXXXXXX/1000
1503NXXXXXX/1000
1504NXXXXXX/1000
1505NXXXXXX/1000
1507NXXXXXX/1000
1508NXXXXXX/1000
1509NXXXXXX/1000
1510NXXXXXX/1000
1512NXXXXXX/1000
1513NXXXXXX/1000
1515NXXXXXX/1000
1516NXXXXXX/1000
1517NXXXXXX/1000
1518NXXXXXX/1000
1520NXXXXXX/1000
1530NXXXXXX/1000
1534NXXXXXX/1000
1539NXXXXXX/1000
1540NXXXXXX/1000
1541NXXXXXX/1000
1551NXXXXXX/1000
1559NXXXXXX/1000
1561NXXXXXX/1000
1562NXXXXXX/1000
1563NXXXXXX/1000
1567NXXXXXX/1000
1570NXXXXXX/1000
1571NXXXXXX/1000
1573NXXXXXX/1000
1574NXXXXXX/1000
1575NXXXXXX/1000
1580NXXXXXX/1000
1585NXXXXXX/1000
1586NXXXXXX/1000
1601NXXXXXX/1000
1602NXXXXXX/1000
1603NXXXXXX/1000
1605NXXXXXX/1000
1606NXXXXXX/1000
1607NXXXXXX/1000
1608NXXXXXX/1000
1609NXXXXXX/1000
1610NXXXXXX/1000
1612NXXXXXX/1000
1614NXXXXXX/1000
1615NXXXXXX/1000
1616NXXXXXX/1000
1617NXXXXXX/1000
1618NXXXXXX/1000
1619NXXXXXX/1000
1620NXXXXXX/1000
1623NXXXXXX/1000
1626NXXXXXX/1000
1630NXXXXXX/1000
1631NXXXXXX/1000
1636NXXXXXX/1000
1641NXXXXXX/1000
1646NXXXXXX/1000
1650NXXXXXX/1000
1651NXXXXXX/1000
1657NXXXXXX/1000
1660NXXXXXX/1000
1661NXXXXXX/1000
1662NXXXXXX/1000
1667NXXXXXX/1000
1669NXXXXXX/1000
1678NXXXXXX/1000
1681NXXXXXX/1000
1682NXXXXXX/1000
1701NXXXXXX/1000
1702NXXXXXX/1000
1703NXXXXXX/1000
1704NXXXXXX/1000
1706NXXXXXX/1000
1707NXXXXXX/1000
1708NXXXXXX/1000
1712NXXXXXX/1000
1713NXXXXXX/1000
1714NXXXXXX/1000
1715NXXXXXX/1000
1716NXXXXXX/1000
1717NXXXXXX/1000
1718NXXXXXX/1000
1719NXXXXXX/1000
1720NXXXXXX/1000
1724NXXXXXX/1000
1727NXXXXXX/1000
1731NXXXXXX/1000
1732NXXXXXX/1000
1734NXXXXXX/1000
1737NXXXXXX/1000
1740NXXXXXX/1000
1747NXXXXXX/1000
1754NXXXXXX/1000
1757NXXXXXX/1000
1760NXXXXXX/1000
1762NXXXXXX/1000
1763NXXXXXX/1000
1765NXXXXXX/1000
1769NXXXXXX/1000
1770NXXXXXX/1000
1772NXXXXXX/1000
1773NXXXXXX/1000
1774NXXXXXX/1000
1775NXXXXXX/1000
1779NXXXXXX/1000
1781NXXXXXX/1000
1785NXXXXXX/1000
1786NXXXXXX/1000
1801NXXXXXX/1000
1802NXXXXXX/1000
1803NXXXXXX/1000
1804NXXXXXX/1000
1805NXXXXXX/1000
1806NXXXXXX/1000
1808NXXXXXX/1000
1810NXXXXXX/1000
1812NXXXXXX/1000
1813NXXXXXX/1000
1814NXXXXXX/1000
1815NXXXXXX/1000
1816NXXXXXX/1000
1817NXXXXXX/1000
1818NXXXXXX/1000
1828NXXXXXX/1000
1830NXXXXXX/1000
1831NXXXXXX/1000
1832NXXXXXX/1000
1843NXXXXXX/1000
1845NXXXXXX/1000
1847NXXXXXX/1000
1848NXXXXXX/1000
1850NXXXXXX/1000
1856NXXXXXX/1000
1857NXXXXXX/1000
1858NXXXXXX/1000
1859NXXXXXX/1000
1860NXXXXXX/1000
1862NXXXXXX/1000
1863NXXXXXX/1000
1864NXXXXXX/1000
1865NXXXXXX/1000
1870NXXXXXX/1000
1872NXXXXXX/1000
1878NXXXXXX/1000
1901NXXXXXX/1000
1903NXXXXXX/1000
1904NXXXXXX/1000
1906NXXXXXX/1000
1907NXXXXXX/1000
1908NXXXXXX/1000
1909NXXXXXX/1000
1910NXXXXXX/1000
1912NXXXXXX/1000
1913NXXXXXX/1000
1914NXXXXXX/1000
1915NXXXXXX/1000
1916NXXXXXX/1000
1917NXXXXXX/1000
1918NXXXXXX/1000
1919NXXXXXX/1000
1920NXXXXXX/1000
1925NXXXXXX/1000
1928NXXXXXX/1000
1929NXXXXXX/1000
1931NXXXXXX/1000
1936NXXXXXX/1000
1937NXXXXXX/1000
1938NXXXXXX/1000
1940NXXXXXX/1000
1941NXXXXXX/1000
1947NXXXXXX/1000
1949NXXXXXX/1000
1951NXXXXXX/1000
1952NXXXXXX/1000
1954NXXXXXX/1000
1956NXXXXXX/1000
1970NXXXXXX/1000
1971NXXXXXX/1000
1972NXXXXXX/1000
1973NXXXXXX/1000
1978NXXXXXX/1000
1979NXXXXXX/1000
1980NXXXXXX/1000
1984NXXXXXX/1000
1985NXXXXXX/1000
1989NXXXXXX/1000
201NXXXXXX/1000
202NXXXXXX/1000
203NXXXXXX/1000
205NXXXXXX/1000
206NXXXXXX/1000
207NXXXXXX/1000
208NXXXXXX/1000
209NXXXXXX/1000
210NXXXXXX/1000
212NXXXXXX/1000
213NXXXXXX/1000
214NXXXXXX/1000
215NXXXXXX/1000
216NXXXXXX/1000
217NXXXXXX/1000
218NXXXXXX/1000
219NXXXXXX/1000
224NXXXXXX/1000
225NXXXXXX/1000
228NXXXXXX/1000
229NXXXXXX/1000
231NXXXXXX/1000
234NXXXXXX/1000
239NXXXXXX/1000
240NXXXXXX/1000
248NXXXXXX/1000
251NXXXXXX/1000
252NXXXXXX/1000
253NXXXXXX/1000
254NXXXXXX/1000
256NXXXXXX/1000
260NXXXXXX/1000
262NXXXXXX/1000
267NXXXXXX/1000
269NXXXXXX/1000
270NXXXXXX/1000
274NXXXXXX/1000
276NXXXXXX/1000
281NXXXXXX/1000
301NXXXXXX/1000
302NXXXXXX/1000
303NXXXXXX/1000
304NXXXXXX/1000
305NXXXXXX/1000
307NXXXXXX/1000
308NXXXXXX/1000
309NXXXXXX/1000
310NXXXXXX/1000
312NXXXXXX/1000
313NXXXXXX/1000
314NXXXXXX/1000
315NXXXXXX/1000
316NXXXXXX/1000
317NXXXXXX/1000
318NXXXXXX/1000
319NXXXXXX/1000
320NXXXXXX/1000
321NXXXXXX/1000
323NXXXXXX/1000
325NXXXXXX/1000
327NXXXXXX/1000
330NXXXXXX/1000
331NXXXXXX/1000
334NXXXXXX/1000
336NXXXXXX/1000
337NXXXXXX/1000
339NXXXXXX/1000
347NXXXXXX/1000
351NXXXXXX/1000
352NXXXXXX/1000
360NXXXXXX/1000
361NXXXXXX/1000
364NXXXXXX/1000
385NXXXXXX/1000
386NXXXXXX/1000
401NXXXXXX/1000
402NXXXXXX/1000
404NXXXXXX/1000
405NXXXXXX/1000
406NXXXXXX/1000
407NXXXXXX/1000
408NXXXXXX/1000
409NXXXXXX/1000
410NXXXXXX/1000
412NXXXXXX/1000
413NXXXXXX/1000
414NXXXXXX/1000
415NXXXXXX/1000
417NXXXXXX/1000
419NXXXXXX/1000
423NXXXXXX/1000
424NXXXXXX/1000
425NXXXXXX/1000
430NXXXXXX/1000
432NXXXXXX/1000
434NXXXXXX/1000
435NXXXXXX/1000
440NXXXXXX/1000
442NXXXXXX/1000
443NXXXXXX/1000
458NXXXXXX/1000
469NXXXXXX/1000
470NXXXXXX/1000
475NXXXXXX/1000
478NXXXXXX/1000
479NXXXXXX/1000
480NXXXXXX/1000
484NXXXXXX/1000
501NXXXXXX/1000
502NXXXXXX/1000
503NXXXXXX/1000
504NXXXXXX/1000
505NXXXXXX/1000
507NXXXXXX/1000
508NXXXXXX/1000
509NXXXXXX/1000
510NXXXXXX/1000
512NXXXXXX/1000
513NXXXXXX/1000
515NXXXXXX/1000
516NXXXXXX/1000
517NXXXXXX/1000
518NXXXXXX/1000
520NXXXXXX/1000
530NXXXXXX/1000
534NXXXXXX/1000
539NXXXXXX/1000
540NXXXXXX/1000
541NXXXXXX/1000
551NXXXXXX/1000
559NXXXXXX/1000
561NXXXXXX/1000
562NXXXXXX/1000
563NXXXXXX/1000
567NXXXXXX/1000
570NXXXXXX/1000
571NXXXXXX/1000
573NXXXXXX/1000
574NXXXXXX/1000
575NXXXXXX/1000
580NXXXXXX/1000
585NXXXXXX/1000
586NXXXXXX/1000
601NXXXXXX/1000
602NXXXXXX/1000
603NXXXXXX/1000
605NXXXXXX/1000
606NXXXXXX/1000
607NXXXXXX/1000
608NXXXXXX/1000
609NXXXXXX/1000
610NXXXXXX/1000
612NXXXXXX/1000
614NXXXXXX/1000
615NXXXXXX/1000
616NXXXXXX/1000
617NXXXXXX/1000
618NXXXXXX/1000
619NXXXXXX/1000
620NXXXXXX/1000
623NXXXXXX/1000
626NXXXXXX/1000
630NXXXXXX/1000
631NXXXXXX/1000
636NXXXXXX/1000
641NXXXXXX/1000
646NXXXXXX/1000
650NXXXXXX/1000
651NXXXXXX/1000
657NXXXXXX/1000
660NXXXXXX/1000
661NXXXXXX/1000
662NXXXXXX/1000
667NXXXXXX/1000
669NXXXXXX/1000
678NXXXXXX/1000
681NXXXXXX/1000
682NXXXXXX/1000
701NXXXXXX/1000
702NXXXXXX/1000
703NXXXXXX/1000
704NXXXXXX/1000
706NXXXXXX/1000
707NXXXXXX/1000
708NXXXXXX/1000
712NXXXXXX/1000
713NXXXXXX/1000
714NXXXXXX/1000
715NXXXXXX/1000
716NXXXXXX/1000
717NXXXXXX/1000
718NXXXXXX/1000
719NXXXXXX/1000
720NXXXXXX/1000
724NXXXXXX/1000
727NXXXXXX/1000
731NXXXXXX/1000
732NXXXXXX/1000
734NXXXXXX/1000
737NXXXXXX/1000
740NXXXXXX/1000
747NXXXXXX/1000
754NXXXXXX/1000
757NXXXXXX/1000
760NXXXXXX/1000
762NXXXXXX/1000
763NXXXXXX/1000
765NXXXXXX/1000
769NXXXXXX/1000
770NXXXXXX/1000
772NXXXXXX/1000
773NXXXXXX/1000
774NXXXXXX/1000
775NXXXXXX/1000
779NXXXXXX/1000
781NXXXXXX/1000
785NXXXXXX/1000
786NXXXXXX/1000
801NXXXXXX/1000
802NXXXXXX/1000
803NXXXXXX/1000
804NXXXXXX/1000
805NXXXXXX/1000
806NXXXXXX/1000
808NXXXXXX/1000
810NXXXXXX/1000
812NXXXXXX/1000
813NXXXXXX/1000
814NXXXXXX/1000
815NXXXXXX/1000
816NXXXXXX/1000
817NXXXXXX/1000
818NXXXXXX/1000
828NXXXXXX/1000
830NXXXXXX/1000
831NXXXXXX/1000
832NXXXXXX/1000
843NXXXXXX/1000
845NXXXXXX/1000
847NXXXXXX/1000
848NXXXXXX/1000
850NXXXXXX/1000
856NXXXXXX/1000
857NXXXXXX/1000
858NXXXXXX/1000
859NXXXXXX/1000
860NXXXXXX/1000
862NXXXXXX/1000
863NXXXXXX/1000
864NXXXXXX/1000
865NXXXXXX/1000
870NXXXXXX/1000
872NXXXXXX/1000
878NXXXXXX/1000
901NXXXXXX/1000
903NXXXXXX/1000
904NXXXXXX/1000
906NXXXXXX/1000
907NXXXXXX/1000
908NXXXXXX/1000
909NXXXXXX/1000
910NXXXXXX/1000
912NXXXXXX/1000
913NXXXXXX/1000
914NXXXXXX/1000
915NXXXXXX/1000
916NXXXXXX/1000
917NXXXXXX/1000
918NXXXXXX/1000
919NXXXXXX/1000
920NXXXXXX/1000
925NXXXXXX/1000
928NXXXXXX/1000
929NXXXXXX/1000
931NXXXXXX/1000
936NXXXXXX/1000
937NXXXXXX/1000
938NXXXXXX/1000
940NXXXXXX/1000
941NXXXXXX/1000
947NXXXXXX/1000
949NXXXXXX/1000
951NXXXXXX/1000
952NXXXXXX/1000
954NXXXXXX/1000
956NXXXXXX/1000
970NXXXXXX/1000
971NXXXXXX/1000
972NXXXXXX/1000
973NXXXXXX/1000
978NXXXXXX/1000
979NXXXXXX/1000
980NXXXXXX/1000
984NXXXXXX/1000
985NXXXXXX/1000
989NXXXXXX/1000

(Note the above does not include the “toll free” area codes nor Canadian area codes; I have separate routes for those).

Now THAT is bad enough, but then imagine having to duplicate this list for each of your extensions (changing only the extension number after the / character), because each will need its own outbound route in order to select its own trunk. In pre-2.8 versions of Asterisk, you could simply copy this list into a text editor, do a search and replace on the /1000 (replacing it with the next extension number), and paste the changed list into a new outbound route. However, with the new way of entering dial plans, you have to enter each line in each field manually, OR (in 2.9 and later) mess with .CSV files, which although easier than manual entry are still a lot harder to deal with than simple cut-and-paste.

But that is actually not the subject of this article; it just sets the stage for what I’m thinking SHOULD be part of Asterisk (or any other soft PBX that requires entering patterns in a similar manner, that is, one line for each pattern). There are actually TWO ways this could be handled, but neither will work at present, as far as I know.

1) Stacking Routes

Let’s suppose you had an outbound route that had all the USA patterns, but did NOT include the extension field. You could have it near the top of your Outbound Route list. And let’s say that you could make the destination of that trunk another “group” of outbound routes rather than a trunk. In that second group, you could have routes with just two patterns per extension:

1XXXXXXXXXX/1000
XXXXXXXXXX/1000

So the call would be effectively pre-screened in the first (primary) group of outbound routes, then sent to the second group (NOT part of the primary group) which would route by extension. That way, you’d only need ONE route with a list of USA patterns, one route with a list of Canada patterns, one route with a list of “toll free” patterns, etc. Each could go directly to a trunk, or to a secondary group of outbound routes.

I think Asterisk might actually be capable of doing something like this (though I’m uncertain of that), but FreePBX definitely is not. So some FreePBX users literally have THOUSANDS of lines of dial patterns in their configuration. Does this slow things down? You betcha, at least when making a configuration change! It takes forever for that darn frog to stop eating flies (if a real frog ate that many flies in that short a time, its gut would probably explode!).

2) Macros

Now here we have a solution that would likely need to be implemented in Asterisk itself. The basic idea is to allow macros in dial patterns. For example, you create a list such as the one above (but without the /extension field – just the number patterns only) and call it [pattern-USA]. Then in your outbound routes, you do something like this:

[pattern-USA]/1000

Changing the extension as needed for each Outbound Route. As noted, this would require implementing this type of macro feature in Asterisk, but it would also necessitate a way to turn off the syntax checking in FreePBX, which is currently impossible.

EDIT: For another way to handle this that probably will work, see How to use the FreePBX [macro-dialout-trunk-predial-hook] macro and regular expressions to blacklist or whitelist outgoing calls on all trunks.

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What you will learn from this book

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