FusionPBX Basic Configuration: Using Google Voice

Previous article: FusionPBX Basic Configuration: Creating an Inbound Route

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

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

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

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

FusionPBX XMPP Profile Edit

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

FusionPBX XMPP Profile Edit showing Context set to public

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

FusionPBX XMPP Manager

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

FusionPBX Module Configuration showing Dingaling disabled

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

FusionPBX Dingaling module configuration

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

FusionPBX Module Configuration showing Dingaling enabled but not started

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

FusionPBX Module Configuration showing Dingaling enabled and started

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

FusionPBX XMPP Manager showing AUTHORIZED status

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

FusionPBX Inbound Route for Google Voice

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

FusionPBX Inbound Route for Google Voice showing Conditions and Actions

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

FusionPBX Dialplan Detail page

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

execute_on_answer=send_dtmf 1

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

FusionPBX Inbound Route for Google Voice showing added action

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

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

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

FusionPBX Outbound Route for Google Voice

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

FusionPBX Outbound Route for Google Voice showing Conditions and Actions

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

FusionPBX Outbound Route for Google Voice – Dialplan Detail

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

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

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

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

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

FusionPBX Outbound Route for Google Voice showing modified Conditions and Actions

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

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

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

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

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

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

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

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

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

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

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

XMPP Manager
Modules

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

Mod dingaling
Channel Variables
Google Voice

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

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

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

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

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

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

1 Comment

  1. The FreeSWITCH bug that caused the excessive delay on outgoing Google Voice calls may have been fixed — see the edit at the end of the second paragraph.

RSS feed for comments on this post

Comments are closed.

Follow

Get every new post delivered to your Inbox.

Join 136 other followers

%d bloggers like this: