How it used to be done: How to use Google Voice for free outgoing calls on an Asterisk/FreePBX system (the no-XMPP way)

 

Important
This article contains text excerpted from 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. Certain edits, including those in the green boxes below, were made on or after December 1, 2013.

EDIT (May 23, 2018): This post is seriously outdated. For more recent information, see How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware. You may also wish to visit this thread at DSLReports for additional information.

It appears that some people are getting upset because Google is dropping the use of its XMPP protocol with Google Hangouts, and there is much speculation that they might drop XMPP support altogether, which could break the method used by PBX software (such as Asterisk, FreeSWITCH, or Yate) and even some hardware to connect to Google Voice.

We would just like to remind everyone that back in the ancient days of Google Voice, Asterisk users had another way to initiate Google Voice calls that did not involve the use of XMPP. While we do not suggest attempting to use this method today, unless absolutely nothing else works, we are reposting a portion of the original instructions here. Again, please note that this method is being reposted as a matter of historical interest only (see this article for more recent recommendations). It is just intended to show that it used to be possible to connect outgoing calls using Google Voice, but without using XMPP.

This method was used by those using Asterisk and FreePBX that wanted to enable free Google Voice outgoing calls. It was assumed that you already had a Google Voice number and has it coming into your system via an Inbound Route (that is, you had it forwarded to a DID that came into your system, that was then handled by an Inbound Route).

Before you began the process, you had to make sure that your Google Voice account was set up correctly.  In your Google Voice account, under the Settings link, Calls tab, you had to make sure the following four options on that page were set up as follows:

Call Screening: Off
Caller ID (in): Display caller’s number (very important!)
Do Not Disturb: Make sure this is unchecked!
Call Options: Make sure this is unchecked!

You also needed to install some Python additions and the pygooglevoice program, assuming you had not done so previously.  Under CentOS you’d do the following from a command prompt:

cd /root
yum -y install python-setuptools
easy_install simplejson
 

Important
If (and only if) you receive a series of error messages while attempting to install simplejson, it may be because your system is running an older version of Python, such as version 2.4 (if some of the error lines contain the string “python2.4”, this is almost certainly the problem). In that case, you can try this (note that the first line might be split into two lines on your display, but should be entered as a single line):

wget http://pypi.python.org/packages/source/s/simplejson/simplejson-2.0.9.tar.gz#md5=af5e67a39ca3408563411d357e6d5e47
tar xzvf simplejson-2.0.9.tar.gz
cd simplejson-2.0.9
sudo python setup.py install

You’d then download the latest version of pygooglevoice and install it, using a line similar to this (this is all one line):

wget http://code.google.com/p/pygooglevoice/downloads/detail?name=pygooglevoice-0.5.tar.gz

Then you’d extract and install pygooglevoice:

tar zxvf pygooglevoice-0.5
cd pygooglevoice-0.5
python setup.py install

There was also a patch that needed to be installed (again this is all one line):

sed -i 's|https://www.google.com/accounts/ServiceLoginAuth?service=grandcentral|https://accounts.google.com/ServiceLogin?service=grandcentral\&continue=https://www.google.com/voice|' /usr/lib/python2.4/site-packages/googlevoice/settings.py

The above was found in this thread in the PBX in a Flash forum, which explains why the patch was needed.

Then you’d open /etc/asterisk/extensions_custom.conf in a text editor and add two new contexts (assuming you were using Asterisk 1.6 or later):

 
[custom-gv-trunk-username
exten => _X.,1,System(gvoice -e username@gmail.com -p userpassword call ${EXTEN} gvregphonenum code &)
exten => _X.,n,Set(DB(gv_dialout_username/channel)=${CHANNEL})
exten => _X.,n,Wait(20)
exten => _X.,n,Noop(Never received callback from Google Voice on channel ${DB_DELETE(gv_dialout_username/channel)} – exiting)
exten => h,1,GotoIf($[“${CHANNEL(state)}” = “Ring”]?:bridged)
exten => h,n,Noop(Hangup on channel ${DB_DELETE(gv_dialout_username/channel)})
exten => h,n,System(gvoice -e username@gmail.com -p userpassword cancel &)
exten => h,n,Hangup()
exten => h,n(bridged),Noop(The channel has been bridged successfully)

Replacing username with the name of the user associated with the Google Voice account (the name before @gmail.com in the associated Gmail account), userpassword with the password of the Google Voice account, gvregphonenumber with the registered phone number in Google Voice that you want to forward calls to (this had to be a number that came into your Asterisk/FreePBX box, and that you had already registered it as a destination in Google Voice, NOT your Google Voice number.  And sometimes you had to use just ten digits, other times you had to add the “1” at the start of the number, and that could vary from account to account so you just had to try and see which worked), and code with a single digit that was one of the following:  1-Home, 2-Mobile, or 3-Work (you’d just use the single digit, not the word, and when you registered the destination phone number with Google Voice you had to tell them if the number was a Home, Work, or Mobile, so the code would correspond to what you’d put there. Some people found that they could omit the code and it would still work, but that wasn’t always true).

In the System() calls it was important not to omit the space and ampersand just before the final parenthesis — this allowed the dial plan to move ahead rather than imposing extra and unnecessary delays on the caller.

One strange thing about this context was that the Noop line was NOT optional – things just didn’t work as expected if it was left out or commented out.
 

Important
On one Asterisk 1.8 system, the following changes were necessary:

  1. The first instance of System(gvoice -e … had to be changed to System(sudo gvoice -e … (adding sudo before gvoice)
  2. In the file /etc/sudoers the following line had to be added: asterisk ALL = NOPASSWD: /usr/bin/gvoice
  3. The hangup portion of the context (everything below the first Noop statement) did not work as intended, and actually cancelled the Google Voice callback!. So it was changed to simply:

exten => h,1,Hangup

As you will see, the line that cancels an abandoned call was added to the second context. The first two changes were necessary because without them, Asterisk could not successfully execute the gvoice program, despite the fact that permissions were set to make it readable and executable by everyone.

The second context that had to be added in /etc/asterisk/extensions_custom.conf was this one:

 
[custom-gv-inbound-username
exten => s,1,NoCDR()
exten => s,n,Bridge(${DB_DELETE(gv_dialout_username/channel)})
 

Important
On one Asterisk 1.8 system it was found necessary to change the above context to read as follows:

 
[custom-gv-inbound-username
exten => s,1,NoCDR()
exten => s,n,GotoIf($[${ISNULL(${DB(gv_dialout_username/channel)})}]?ext-did-0002,gvregphonenum,1)
exten => s,n,Bridge(${DB_DELETE(gv_dialout_username/channel)})
exten => s,n,System(sudo gvoice -e username@gmail.com -p userpassword cancel &)
exten => s,n,Hangup()

The purpose of the line that begins with exten => s,n,GotoIf… is to correctly route the incoming call in case you initiated a callback from the Google Voice web page. The string gvregphonenum is replaced by the registered phone number in Google Voice that you are forwarding calls to, which should also be the same as the DID in your Inbound Route for Google Voice calls – this is NOT your Google Voice number! This line is optional, and note that it sends calls to the context ext-did-0002 in extensions_additional.conf, which could possibly be different in differently-configured versions or future versions of FreePBX. If it doesn’t work for you, you can leave the entire line out, but you won’t be able to initiate callbacks from your Google Voice page.

The purpose of the line that begins with exten => s,n,System… is to cancel the call in case the caller has hung up before the callback from Google Voice is received. If the call is not cancelled, weird stuff happens! You can omit the “sudo” if you did not find it necessary to add it above.

Again replacing all instances of username and userpassword with the name and password of the user associated with the Google Voice account. After saving those changes you would then go into the FreePBX GUI, go to the Tools menu, Custom Destinations module, and create a new Custom Destination. In the Custom Destination: text box you’d enter this string:

custom-gv-inbound-username,s,1

In the Description: field, you could use a meaningful description such as Google Voice Bridge username and then click on “Submit Changes.” After saving that you’d go into Trunk settings and create a new CUSTOM trunk with these settings:

Maximum Channels: set to 1
Dial Rules: Use what you like, it’s suggested that you at least add 1+NXXNXXXXXX but if your area allows seven digit dialing, you may also want to add one like 1areacode+NXXXXXX where areacode is replaced with your local three digit area code.
Custom Dial String: Set to Local/$OUTNUM$@custom-gv-trunk-username — once again, replace username with the name of the user associated with the Google Voice account.

Once you had created and saved this trunk, it could be used as a trunk selection for any USA/Canada Outbound Route.

One assumption was that you had already set up Google Voice to send incoming calls to your Asterisk system via a DID that did not change the incoming Caller ID number. Normally this would be accomplished by getting a DID from some provider (either a free one or one you paid for — it didn’t matter as long as they would pass incoming Caller ID number correctly). Once that was working, you’d create a second inbound route for that same DID, without changing the original in any way — this would be a new Incoming Route, which would be set it up as follows:

Description: Anything meaningful, such as Username Google Voice”.

DID Number: Same as on your other Inbound Route that handles your Google Voice traffic.

Caller ID number: This had to be be your Google Voice number (the one associated with your Google Voice account), but depending on how your DID provider sent Caller ID, you might have to specify it as either a ten or eleven digit Caller ID, or even +1 followed by ten digits.  Whatever format your DID provider used, you had to match their format, which sometimes meant watching the Asterisk CLI during a test call to see what format they used. If it didn’t match what they sent, it wouldn’t work.

Destination: the Custom Destination created above (e.g. Custom Destinations: Google Voice Bridge username).

No other settings of the Inbound Route were changed and in particular, you were advised not to set a CID Lookup Source because it would cause an unwanted delay in connection time and was totally useless in this route, and there’s no reason to do so since this route is only triggered when a single Caller ID comes in).

Once you had submitted these changes, you should have been able to add your Google Voice custom trunk as a trunk selection for one or more of your USA/Canada Outbound Routes.

If it didn’t work it was generally one of three things. Either the Custom Trunk hadn’t been specified as a destination in the appropriate Outbound Route, or the incoming Caller ID of the Google Voice call didn’t exactly match what you set up in the Inbound Route you created, or you got something wrong in extensions_custom.conf such as the username or password (or you missed a place where you were supposed to change one of those items).

For test purposes, you could go to a Linux command prompt (not a CLI prompt in Asterisk!) and try entering a gvoice command directly, using this format (note this is all one line):

gvoice -e username@gmail.com -p userpassword call numbertocall gvregphonenum code

All of those values are as explained earlier, except for numbertocall, which had to be a USA or Canada phone number in 11 digit format.  Yes, the number to call had to be in 11 digit format (with the leading “1”) whereas the gvregphonenum might (or might not) need to be TEN digits (no leading “1”) – go figure.  If it worked from the command line then you needed to double check your values in extensions_custom.conf.  If it did not work from the command line, then either there was something wrong with your pygooglevoice installation, or with Python on your system (you had to have at least Python version 2.4 or higher), or you could have been using incorrect values (EDIT: Or, on some systems, it might be necessary to execute the gvoice command using sudo from within Asterisk, as described above).  And, some people got confused over the fact that that the “gvregphonenum” value was NOT supposed to be their Google Voice number, but instead the number to which Google Voice forwarded their calls, and it had to be a number that had been previously registered as a destination with Google Voice.

That’s the basics of how it was done. Note this is not intended to be a guide as to how to set this up now, since many things have changed since then. Just because this method worked back then does not mean it will still work today, and it’s definitely slower in the setup of calls than more recent methods. However, it is worth noting that at no point was the XMPP protocol used. It’s also worth mentioning that there are other programs that can interact with Google Voice besides PyGoogleVoice (see for example Google-Voice-PHP-API, google-voice-java, SharpGoogleVoice, voice.js, etc.) that may or may not be more suitable for use in this type of application.

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

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.

Link: Google Voice Customers Cry Out For Help, No One At Google Hears Them

 

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.

The Consumerist is just waking up to a fact that many of us Google Voice users realized a long time ago:  There is virtually no such thing as customer support at Google Voice.  For example, they still haven’t fixed the bug that even if you disable call screening, it’s still turned on if the calls are delivered via Google Chat, and that’s been a problem for at least three or four years now.  Nor have they come up with a way to change the amount of time the call rings at the destination before Google snatches it back and sends it to Google Voice’s voicemail (approximately 25 seconds is just too short in some situations).

The Consumerist article doesn’t touch on either of those specific issues, but at least they’re beginning to understand that the complete lack of effective support at Google Voice can really be a problem:

Google Voice Customers Cry Out For Help, No One At Google Hears Them (The Consumerist via the Wayback Machine)

Yes, I know it’s a free service and some will say you get what you pay for, and I guess that will fly as long as the service remains free, but when they charge for a service (such as the number port mentioned in the article) then they should at least have an effective way to address issues and complaints about the services people have paid for (and perhaps not received)!

 

Link to POSSIBLE method of porting a landline phone number to Google Voice for free (well, except for the $20 that Google Voice charges)

 

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.

Google Voice will only allow you to port cell phone numbers to their service (don’t ask ME why — seems stupid, but that’s their rule) so if you want to port a landline number, you first have to temporarily port it to a cell phone provider, then from there port it to Google Voice. Most of the published methods that I have seen for doing this involve paying out some small sum (usually around $20) to get a “disposable” cell phone (so after adding the $20 that Google Voice changes to do the port you are out almost $40), however I just stumbled across a thread that suggests it may be possible to do it for free, IF you have (or can borrow) an old Verizon or Page Plus cell phone that’s not currently being used.  Note this may not work in all areas (there are still areas of the country where Google Voice can’t port numbers) and I don’t guarantee it in any case because I haven’t personally tried it, but if you’ve been thinking of porting your landline number to Google Voice, this MIGHT save you a few bucks:

Post on DansDeals.com Forums

Again, although it’s not clear from this thread, Google Voice will still charge you $20 to do the port, but if you can get this to work it could save you some money.  Note that if you are served by some Podunk (independent) telephone company there’s a good chance it won’t work, so keep that in mind if losing your number would be a major catastrophe for you.

A couple of links for those using a Google Voice number attached to their primary Gmail account, especially Asterisk users

 

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 article was originally posted in January, 2011 and may contain outdated information.

If, despite all the advice you’ve read here and elsewhere, you’ve not created a separate Gmail account to use with your Google Voice service (using this form to attempt to get your existing number transferred to the new account, if that’s your desire), then these links are for you:

1.  Asterisk hack: make your Google Talk client invisible:

It’s been a too-busy-to-write week, but I found some time the last few evenings to brush up my C coding (only hacking at this point, really) to make Asterisk 1.8 do something I’ve wanted from the beginning: Google Talk’s invisible mode for the Google Voice integration. ….. You might want to use this feature if, like me, your Google Voice number is attached to your main GMail account. I don’t use the chat features but I appear online to anyone who has me in their contact list, as long as Asterisk is logged in, and that has the potential to draw unwanted instant messages (that will never get answered).

Full article here.

2. Avoiding the problem of missing calls when you are logged into your Gmail account:

NOTE: Also see: Not receiving some incoming Google Voice calls? Try increasing the priority.

This is posted on the OBiTALK forum, but likely applies to Asterisk users as well.  I specifically suggest that you read the third and fifth posts in the thread (posted by user “Agate”).

Link to thread on OBiTALK forum.

By the way, something I’ve been looking for, for those who use Asterisk 1.8+ with Google Voice but prefer to use the Google Voice voicemail instead of Asterisk’s, is an easy way to get a count of new voicemail messages in a specific Google Voice account. This information could then be used in some type of notification system.  What I’m specifically NOT looking for is something that requires the use of pygooglevoice — since all we want is a voicemail count, that’s overkill.  I’d also prefer a solution that doesn’t require downloading a huge XML file just to extract a voicemail count (since this is something you’d check rather frequently, pulling down about 10,000% more data than you really want just doesn’t cut it).  If anyone know of an elegant way to do this, I’d love to hear it.

Asterisk 1.8.x and FreePBX users: How to NOT answer Google Voice calls UNTIL the called extension answers

 

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

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

This article was originally published in December, 2010 and may contain out-of-date information.

Many folks are experimenting with Asterisk 1.8.x and Google Voice.  In most cases the way it’s set up is that when a Google Voice call arrives, Asterisk answers the call, then sends a touch-tone digit “1” to Google Voice to answer the call, then proceeds to ring the destination extension.  This is necessary because when you configure Google Voice to use a Gtalk destination, they require you to press “1” to accept the call, even if you’ve configured Google Voice not to require that.  I don’t know if this is a bug in Google Voice or if they did it that way deliberately for some reason, but answering the call and accepting it upon arrival at the PBX has a few unintended side effects:

  • If your callers pay for long distance by the minute, they get charged from the moment the called extension begins ringing – even if you never answer the call.
  • You can’t use Google Voice’s Voicemail, nor their transcription service, because you’ve already answered the call.
  • Callers may hear a confusing double ringing tone at the start of ringing — one ring from Google Voice and the rest from Asterisk.

On the other hand, there are some advantages to doing it that way:

  • Because you’ve answered the call, you can let the extension ring as long as you like before sending it to voicemail, and Google Voice won’t snatch it away in 25 seconds and send it to their voicemail.
  • You can use Asterisk’s voicemail, if that’s what you prefer.

For those who’d prefer to let Google Voice handle their voicemail, or who object to making callers pay to listen to up to 25 seconds of ringing, there is a way to not answer the call and send the touch tone “1” until  after the destination extension has actually picked up the call.  If you are using plain vanilla Asterisk, all you have to do is make sure your Dial() command contains two additional options.  Consider this example line of Asterisk dialplan:

exten => gvoicein,n,Dial(SIP/1004,35,rTWtwaD(:1))

The important part here is the aD(:1) — the other options can be whatever you’d normally use, if any, but it’s the aD(:1) that does the magic. Now at this point, if you’re a FreePBX user you may be wondering how on earth you can modify the Dial() string, since the code that generates it is buried deep within the bowels of FreePBX. Fortunately, there is a way. Consider the following piece of code that might be used in extensions_custom.conf to bring in Google Voice calls:

[googlein]
exten => _[0-9a-z].,1,Noop(Incoming Google Voice call for ${EXTEN})
exten => _[0-9a-z].,n,Set(CALLERID(name)=${CUT(CALLERID(name),@,1)})
exten => _[0-9a-z].,n,GotoIf($["${CALLERID(name):0:2}" != "+1"]?notrim)
exten => _[0-9a-z].,n,Set(CALLERID(name)=${CALLERID(name):2})
exten => _[0-9a-z].,n(notrim),Set(CALLERID(number)=${CALLERID(name)})
exten => _[0-9a-z].,n,Wait(1)
exten => _[0-9a-z].,n,Answer
exten => _[0-9a-z].,n,Wait(1)
exten => _[0-9a-z].,n,SendDTMF(1)
exten => _[0-9a-z].,n,Goto(from-trunk,gv-incoming-${CUT(EXTEN,@,1)},1)
exten => h,1,Macro(hangupcall,)

With this context you’d use gv-incoming-username (where username is the part of the associated gmail address before the @) as the DID in your inbound route — a DID doesn’t have to be numeric even if FreePBX whines about it, and the advantage is you only need one context to handle incoming calls for all your Google Voice accounts.  This particular context is slightly modified from one found in the PBX in a Flash forum, but note that it contains these four lines that wait ONE second, answer the call, wait ONE second (you do NOT have to wait two seconds, despite what any other article may say, and in fact the one second wait might be unnecessary), and then send the touch tone digit 1:

exten => _[0-9a-z].,n,Wait(1)
exten => _[0-9a-z].,n,Answer
exten => _[0-9a-z].,n,Wait(1)
exten => _[0-9a-z].,n,SendDTMF(1)

You will find those four lines, or some variation on them (sometimes just the last three), in just about every published method for using Google Voice with Asterisk and FreePBX.  But, in FreePBX at least, you can replace them with this:

exten => _[0-9a-z].,n,Set(DIAL_OPTIONS=${DIAL_OPTIONS}aD(:1))

This slides the aD(:1) into the options that will be used with the Dial command, so when the extension answers, the call will be answered and then the touch tone “1” will be immediately sent to Google Voice, and then the audio between Google Voice and the called extension will be bridged as usual.

Unfortunately, or maybe fortunately depending on your point of view, it appears that if the call should go to Asterisk’s voicemail, the call will not be answered and the DTMF 1 will never be sent.  This means that if, for whatever reason, you don’t answer the incoming call, after 25 seconds it will go to Google’s voicemail.  There are doubtless ways around that (and if anyone’s truly interested, leave a comment and I’ll suggest a way that may work, that involves routing the incoming call to a ring group first) but I suspect that the majority of people who want to do this will be doing it because they want to use Gmail’s voicemail.

I’ve tested this and it works for me, though I would not use it on a regular basis because I prefer Asterisk’s voicemail.  If it doesn’t work for you for some reason, the only suggestion I can offer is adding a w before the :1, so the added options look like aD(w:1) – that will add a one-half second delay before the “1” is sent, and more than likely it won’t help one bit, but may cause callers to not hear your “hello” or other greeting.  But, you can try it and see — at least one user has reported it to be necessary.  If that doesn’t work, I probably won’t be able to help you but if you leave a comment, maybe someone else can.

And, should anyone from Google Voice read this, it would be really helpful if you’d do two things:

  1. Give us a way to disable Google Voice’s voicemail so we don’t have to resort to hacks like this to discourage callers from leaving a message there.
  2. Fix the bug (or “feature”) so that when we turn off call screening, it’s off for ALL destinations, including Gtalk!

How to stop people from leaving messages in your Google Voice voicemail box

 

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.

One irritating thing about Google Voice is their voicemail – they must be really proud of it, because they give you no way to turn it off (at least not that I can find), and worse yet, they don’t even let you pick the timeout before your Google Voice calls go to voicemail.  If people actually had to pay for their service I’m sure they’d get boatloads of complaints, but since it’s free and since Google doesn’t seem to care much what users think, we are stuck with their voicemail whether we want it or not. However, there are some situations where you really don’t want to have to check Google’s voicemail, so how do you discourage people from leaving a message?

The answer is simple, and probably 99.9% effective: Change your greeting to a busy signal! Most people, and even most automated calling equipment, will hang up after receiving a busy signal, and will not leave a message (and if anyone does, it’s probably a stupid robo-caller that you can safely ignore).

So how do you change your greeting in Google Voice? Glad you asked…

To start with, download this audio file (right-click on the link and save it to your hard drive). It is 24 seconds of North American busy signal, followed by the DTMF # button (the latter is needed to signal the end of the greeting).

Now, what you have to do is go to your Google Voice settings, Voicemail & Text tab, and in the Voicemail Greeting section click on “Use phone to record a new greeting.” I suggest you try this once or twice just to get the hang of how it works (you can delete any recording you make on the same page). Note that once you’ve recorded your first greeting, the button will change to say just “Record new.”

Google Voice - Location of "Record New Greeting" button

Now, the obvious thing to do here is to hold the phone up to your computer’s speaker and play the audio file after Google calls you to record the greeting. If you’re careful about your volume levels it might work, but I don’t recommend it.

A better method is to temporarily redirect your Google Voice callback so that it comes to a softphone on your computer, preferably one that has the ability to select audio inputs and outputs.  How to do that is left as an exercise for the reader, but I can tell you that the free version of Zopier will allow you to select inputs. You’ll also need an audio program that can play back .wav files and allows you to select outputs (an example for the Mac would be Vox), and depending on your computer, you may need a third piece of software that allows you to redirect the output of one program to the input of another (for example, on a Mac you can use Soundflower). On a Mac you’d go into the audio player preferences, set the output to go to the redirection software, then set the softphone to get its audio input from the redirection software.

Vox audio player output settings
Zoiper softphone audio input settings

After doing this, get Google Voice to call your softphone, answer the call and immediately click “play” on the audio player software (into which you will have pre-loaded the audio file) and if all goes well it will play the file and at the end, after the DTMF # tone is played, Google Voice should play back the file, and ask you to accept it or try again. If you hear some ringing tone in the playback prior to the busy signal, just click “2” on Zoiper’s touch-tone keypad to try again (when you are given that option) and then as soon as you hear the beep, click “play” again. When it’s right, click the “1” on Zopier’s touch tone keypad when given the option. You can confirm that this is set as the default from the Google Voice page mentioned above. Also, note that by using the Google Voice “Groups” feature, you can play this “greeting” only to certain callers, if for some reason you want some people to actually be able to leave you voicemail in your Google Voice voicemail box.

I know that Zoiper is cross-platform and can be used under all major operating systems, and I’m pretty sure there are audio redirection programs available for Windows and Linux, though I don’t know what they are called offhand (if you do, please feel free to leave a comment, provided the software you suggest is free to use — I’m not going to promote any commercial software for this purpose because I’m pretty sure there is free software available, and in any case, it may even be possible to achieve this function from the Windows sound control panel, but it’s been so long since I’ve tried to do anything like this in Windows that I don’t remember how it’s done, I just know it’s possible).

Related Link:
Proof of concept: Automatically transfer Google Voice voicemail to Asterisk voicemail

Link: Using FreeSWITCH to add Google Voice to Asterisk

 

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

EDIT (2018): This article is extremely out-of-date and in no way useful today, and will probably be removed from this site at some point in the future. You might find this article more useful: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware.

For those of you using Asterisk, Bill over at the PSU VoIP blog has come up with a way to interface Asterisk with Google Voice, by co-installing FreeSWITCH (which also supports Google Voice).  Turns out that Asterisk and FreeSWITCH can co-exist on the same server, though you do have to change the configuration a bit so they don’t compete for the same ports.  Anyway, Bill has come up with a how-to on adding Google Voice integration to current versions of Asterisk, so if that interests you, head on over and have a look:

Using FreeSWITCH to add Google Voice to Asterisk

The bonus is that once you get FreeSWITCH installed you can play around with it and look at some of its other features, if you are so inclined. Of course, the Asterisk folks could backport the Google Voice support to previous versions and make it unnecessary to do things like this, but I’m not holding my breath.

EDIT (January 26, 2012): The Google Voice channel drivers in Asterisk 1.8 have become unreliable enough (in my personal opinion, anyway) that I just used the technique shown in this article, and I must say that it works a LOT better than Asterisk 1.8’s Google Voice support.  I also added some comments to that article (probably too many!) that among other things show how I got it working for multiple Google Voice accounts.  So I would now recommend using this method to bridge Asterisk to Google Voice in preference to using Asterisk 1.8’s native channel drivers (unless you are very short on memory and/or storage space) — it just works, and calls connect faster.  Read the article AND the comments under it first, so you’ll know what to expect, and do be aware that it takes a relatively LONG time to compile and install FreeSWITCH (compared to Asterisk).  At points during the installation it may look like it’s stuck in an endless loop, but it really isn’t. Just go away and take a walk outside or something, and come back in a while and it should be done.