Month: October 2012

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.

How to force FreePBX to immediately retry the same trunk again if it fails the first time even though the FreePBX developers apparently don’t want you to be able to do that

 

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

This is going to be a very barebones explanation because to be honest I’m really not motivated to make things easier for FreePBX users anymore.  I really want you to think about trying other PBX software that doesn’t treat its users as if they need afternoon naps and their diapers changed occasionally.

But I have found a way to overcome the limitation, however you need Webmin or phpMyAdmin, and you need to be very careful because one wrong click could screw up your database.  I use Webmin so that’s what I’ll be talking about here.  I am NOT telling you to do this on your system, and if you should choose to follow my example and mess up your system, don’t email me about it because I can’t help you and I’m warning you that this might be dangerous if you don’t know what you are doing, and I will not assume any responsibility for what you choose to do.  You break it, you own all the parts.  Also note that I’m doing this on an FreePBX 2.8 system, so if you are using another version, things might be different from what I’m describing.  This is what I have done that worked for me; it may or may not work for you, but if you wish to attempt it I strongly recommend that you make sure you have a full system backup (MondoRescue is a good program to use to create such a backup).

In Webmin, go into Servers | MySQL Database Server and in the MySQL Databases section, click on the icon or label (NOT the checkbox) for asterisk.

On the next page, you may get a message saying “There are too many tables to display. Find tables matching” followed by a search field.  If so, enter the word “Outbound” and click “Search”.

Click on the icon or label (NOT the checkbox) for outbound_route_trunks

At this point, if your browser supports it, duplicate the tab so you have two tabs showing this page.  In the first, click the Export as CSV button and in the next page, select “Yes” for “Include column names in CSV?“and select “Display in browser” as the Export Destination and then click Export Now.  You should see a display showing your Outbound Routes, but since they are all identified by numbers, you won’t know which is which.  Leave this tab open and do not reload it.  This is a “snapshot” of your Outbound Route trunk selections as the database sees them, before you make any changes.

Now open another browser tab and go to the Outbound Route page for the route where you want to select the same trunk twice.  In the Trunk Sequence for Matched Routes section, where you’d add the desired trunk the second time, add ANY other trunk instead, and Submit Changes, but don’t click the orange bar to apply the configuration changes.  Do make sure that everything is correct in the route configuration because after you finish this you won’t be able to make any changes without repeating all these tedious steps, which would be totally unnecessary if… never mind.  And make a mental note of the total number of trunks in the list, and don’t make any changes to any other Outbound Routes until you’ve completed this process. EDIT: Also, while that same Outbound Route page is open, look at your browser’s URL bar and note the address that is open — that may include the route_id number that will be needed in the next step. For example, if the address is https://your.server.address/admin/config.php?display=routing&extdisplay=21 then 21 is most likely the route_id number.

Now go back to the duplicated Webmin tab (the one NOT showing the CSV display), and click View Data. Under route_id, each outbound route is identified by a number, and the number of times that number appears equals the number of trunks in the Trunk Sequence for Matched Routes section,  Note that if there are more than 25 entries you may have to page through them to find the route you are trying to change.  So, let’s say that your Outbound Route originally had one trunk selection, and you added the second one which is incorrect, just to force FreePBX to accept it, so there is now a total of two trunks for that route.  You’d look through the route_id’s to find one where the route_id number is listed twice (as many times as the number of trunk selections) and note the route_id number.  You would then flip back to the other tab showing the CSV output to see if that route was only listed once (only had one trunk selected) when you took the CSV “snapshot”.  If so, you have found the correct route; if not, keep looking.

The trunk order is determined by the number in the seq column and is zero based, so if you had two trunks total, and the first trunk was correct and the second was the incorrect trunk that you added, then look for the line with the correct route_id number and 0 in the seq column, and note the trunk_id for that line.  Now find the line with the same route_id number but with 1 in the seq column.  Make a mental note of the trunk_id so you can change it back if you somehow managed to get the wrong route, and click the checkbox at the start of the line and then click Edit Selected Rows.  That row should turn into text boxes and what you want to do is change the trunk_id so that it matches that of the trunk selection you want to duplicate (the one with 0 in the seq column in this example).  Click Save.

Go back to the Outbound Route page and do not click Submit Changes.  Instead, reload the page, or go to another Outbound Route and come back.  It should show the duplicated trunk where the incorrect trunk selection was.  Once again, do not click Submit Changes, but NOW you can click the orange bar to apply the configuration changes. Remember that if you EVER click “Submit Changes” on this page from now on, the duplicated trunk will be removed and you get to do this all over again (unless you can figure out how to modify the source code so it doesn’t do that). 🙁

If you use phpMyAdmin you should be able to do something similar.  Just remember that every time you need to go through this tedious procedure, you can silently “thank” the FreePBX developers for once again making the extra effort to make life difficult for their experienced users.

If you’ve somehow managed to screw up your system by doing this (and I hope you don’t), just remember I warned you that doing this could be dangerous, but on the flip side, now would be a really good time to try some other software (you could try FusionPBX, for example).

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.

Recent Posts

Recent Comments

Archives

Categories

Meta

GiottoPress by Enrique Chavez