# Asterisk Project : Calling using Google

Added by mdavenport , edited by rnewton on Jun 03, 2013

Icon

This new page replaces the old page. The old page documents behavior that is not functional or supported going forward. This new page documents behavior as of Asterisk 11. For more information, please see the blog posting http://blogs.digium.com/2012/07/24/asterisk-11-development-the-motive-for-motif/

# Prerequisites

Asterisk communicates with Google Voice and Google Talk using the chan_motif Channel Driver and the res_xmpp Resource module. Before proceeding, please ensure that both are compiled and part of your installation. Compilation of res_xmpp and chan_motif for use with Google Talk / Voice are dependant on the iksemel library files as well as the OpenSSL development libraries presence on your system.

Calling using Google Voice or via the Google Talk web client requires the use of Asterisk 11.0 or greater. Older versions of Asterisk will not work.

For basic calling between Google Talk web clients, you need a Google Mail account.

For calling to and from the PSTN, you will need a Google Voice account.

In your Google account, you'll want to change the Chat setting from the default of "Automatically allow people that I communicate with often to chat with me and see when I'm online" to the second option of "Only allow people that I've explicitly approved to chat with me and see when I'm online."

IPv6 is currently not supported. Use of IPv4 is required.

Google Voice can now be used with Google Apps accounts.

## RTP configuration

ICE support is required for chan_motif to operate. It is disabled by default and must be explicitly enabled in the RTP configuration file rtp.conf as follows.

    [general]
    icesupport=yes

If this option is not enabled you will receive the following error message.

    Unable to add Google ICE candidates as ICE support not available or no candidates available

## Motif configuration

The Motif channel driver is configured with the motif.conf configuration file, typically located in /etc/asterisk. What follows is an example configuration for successful operation.

### Example Motif Configuration

    [google]
    context=incoming-motif
    disallow=all
    allow=ulaw
    connection=google

This general section of this configuration specifies several items.

1. That calls will terminate to or originate from the incoming-motif context; context=incoming-motif
2. That all codecs are first explicitly disallowed
3. That G.711 ulaw is allowed
4. The an XMPP connection called "google" is to be used

Google lists supported audio codecs on this page - https://developers.google.com/talk/open_communications

Per section, 5, the supported codecs are:

1. PCMA
2. PCMU
3. G.722
4. GSM
5. iLBC
6. Speex

Our experience shows this not to be the case. Rather, the codecs, supported by Asterisk, and seen in an invite from Google Chat are:

1. PCMA
2. PCMU
3. G.722
4. iLBC
5. Speex 16kHz
6. Speex 8kHz

It should be noted that calling using Google Voice requires the G.711 ulaw codec. So, if you want to make sure Google Voice calls work, allow G.711 ulaw, at a minimum.

## XMPP Configuration

The res_xmpp Resource is configured with the xmpp.conf configuration file, typically located in /etc/asterisk. What follows is an example configuration for successful operation.

### Example XMPP Configuration

    [general]
    [google]
    type=client
    serverhost=talk.google.com
    username=example@gmail.com
    secret=examplepassword
    priority=25
    port=5222
    usetls=yes
    usesasl=yes
    status=available
    statusmessage="I am available"
    timeout=5

The default general section does not need any modification.

The google section of this configuration specifies several items.

1. The type is set to client, as we're connecting to Google as a service; type=client
2. The serverhost is Google's talk server; serverhost=talk.google.com
3. Our username is configured as your_google_username@gmail.com; username=your_google_username@gmail.com
4. Our password is configured using the secret option; secret=your_google_password
5. Google's talk service operates on port 5222; port=5222
6. Our priority is set to 25; priority=25
7. TLS encryption is required by Google; usetls=yes
8. Simple Authentication and Security Layer (SASL) is used by Google; usesasl=yes
9. We set a status message so other Google chat users can see that we're an Asterisk server; statusmessage="I am available"
10. We set a timeout for receiving message from Google that allows for plenty of time in the event of network delay; timeout=5

#### 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.

## Phone configuration

Now, let's create a phone. The configuration of a SIP device for this purpose would, in sip.conf, typically located in /etc/asterisk, look something like:

    [malcolm]
    type=peer
    secret=my_secure_password
    host=dynamic
    context=local

## Dialplan configuration

### Incoming calls

Next, let's configure our dialplan to receive an incoming call from Google and route it to the SIP phone we created. To do this, our dialplan, extensions.conf, typically located in /etc/asterisk, would look like:

    [incoming-motif]
    exten => s,1,NoOp()
     same => n,Wait(1)
     same => n,Answer()
     same => n,SendDTMF(1)
     same => n,Dial(SIP/malcolm,20)

Icon

Did you know that the Google Chat client does this same thing; it waits, and then sends a DTMF 1. Really.

This example uses the "s" unmatched extension, because we're only configuring one client connection in this example.

In this example, we're Waiting 1 second, answering the call, sending the DTMF "1" back to Google, and then dialing the call.
We do this, because inbound calls from Google enable, even if it's disabled in your Google Voice control panel, call screening.
Without this SendDTMF event, you'll have to confirm with Google whether or not you want to answer the call.

Using Google's voicemail

Icon

Another method for accomplishing the sending of the DTMF event is to use Dial option "D." The D option tells Asterisk to send a specified DTMF string after the called party has answered. DTMF events specified before a colon are sent to the called party. DTMF events specified after a colon are sent to the calling party.

In this example then, one does not need to actually answer the call first, though one should still wait at least a second for things, like STUN setup, to finish. This means that if the called party doesn't answer, Google will resort to sending the call to one's Google Voice voicemail box, instead of leaving it at Asterisk.

    exten => s,1,Dial(SIP/malcolm,20,D(:1))

Filtering Caller ID

Icon

The inbound CallerID from Google is going to look a bit nasty, e.g.:

    +15555551212@voice.google.com/srvres-MTAuMjE4LjIuMTk3Ojk4MzM=

Your VoIP client (SIPDroid) might not like this, so let's simplify that Caller ID a bit, and make it more presentable for your phone's display. Here's the example that we'll step through:

    exten => s,1,NoOp()
     same => n,Set(crazygooglecid=${CALLERID(name)})
     same => n,Set(stripcrazysuffix=${CUT(crazygooglecid,@,1)})
     same => n,Set(CALLERID(all)=${stripcrazysuffix})
     same => n,Dial(SIP/malcolm,20,D(:1))

First, we set a variable called crazygooglecid to be equal to the name field of the CALLERID function. Next, we use the CUT function to grab everything that's before the @ symbol, and save it in a new variable called stripcrazysuffix. We'll set this new variable to the CALLERID that we're going to use for our Dial. Finally, we'll actually Dial our internal destination.

### Outgoing calls

Outgoing calls to Google Talk users take the form of:

    exten => 100,1,Dial(Motif/google/mybuddy@gmail.com,,r)

Where the technology is "Motif," the dialing peer is "google" as defined in xmpp.conf, and the dial string is the Google account name.

We use the Dial option "r" because Google doesn't provide ringing indications.

Outgoing calls made to Google Voice take the form of:

    exten => _1XXXXXXXXXX,1,Dial(Motif/google/${EXTEN}@voice.google.com,,r)

Where the technology is "Motif," the dialing peer is "google" as defined in motif.conf, and the dial string is a full E.164 number, sans the plus character.

Again, we use Dial option "r" because Google doesn't provide ringing indications.

## Comments:

Can you clarify which configuration file the icesupport=yes directive belongs in? Thanks! Posted by tim.savage at Nov 02, 2012 03:06
Done! Posted by jcolp at Nov 02, 2012 06:05
Thanks for the quick reply, Joshua. I was able to get it working with very little trouble. Another question, are there any Motif specific channel variables, and if so, is there a list available? I do realize this was just released, and the documentation may not be complete yet, so I'll try my best to be patient. What I'm trying to accomplish is having multiple Google Voice accounts configured, and be able to route inbound calls accordingly. I was able to do this with the gtalk driver by parsing the associated Google account name from the extension variable (with a wildcard match in the dialplan), but that info doesn't appear to be passed along with the new Motif driver, or at least not in the same fashion as the gtalk driver. Using a channel variable would seem like much less of a kludge than my previous solution. Posted by tim.savage at Nov 02, 2012 11:46
It doesn't expose any channel variables right now, unfortunately. To accomplish what you are referring to you'd have to create separate contexts. Posted by jcolp at Nov 02, 2012 11:48
Of course! That's so obvious, I can't believe I didn't think of that in the first place. Still looking forward to having channel variables for other trickery, but I'm good to go for now. Thanks again for your help, and let me say, I am really pleased with the new driver. Here's hoping the moving target that was gtalk is now finally pinned down. Posted by tim.savage at Nov 02, 2012 12:30
The Caller ID filtering code doesn't work on certain telephone services: First off, in my area we dial 7 digits for in-State calls and all 10 digits for out-of-state calls. If I call from my home landline, I get one ring, then it hangs up on me. Destination extension never rings. If I call from my cell phone, same thing. If I call from my home landline and dial all ten digits, the same thing happened. If my friend in CA calls long distance, it works perfectly fine for him. Same for a client I have in another state. I commented out lines, one at a time, and determined that the second and third lines of the Caller ID code are causing Asterisk to drop the call if it is in a local area code. Has something to do with the variables or something. After several forum searches, here is what I did instead for the dial plan:
    exten => s,1,NoOp()
     same => n,Wait(1)
     same => n,Answer()
     same => n,SendDTMF(1)
     same => n,Set(CALLERID(number)=${CALLERID(name):2:10})
     same => n,Set(CALLERID(name)=External Line)
     same => n,Dial(SIP/100,30)
     same => n,Voicemail(100@internal)
Posted by newageserver at Jan 21, 2013 13:11
The caller ID tricks above are not working for incoming calls that block their caller ID. If a calls comes with blocked ID, the solution above from Andrew will present the call as +@voice.go The solution is to use the CUT function. Below is the solution I have for my home system using Google voice, and digium phones. If a call comes, I strip out the @voice.google.com , this is so I can use the function CALL BACK correctly. If a call comes with blocked ID, I make the caller ID an empty string and call the function PrivacyManager(), which will ask the caller to enter their phone number. On my phone, the call will then have the number they entered (which could be false), and Privacy Manager as a name. You do not need to use the PrivacyManager, but it's a cool feature to play with. The code below picks up the phone, strip whatever is after the @ when the caller id comes (xxxxx@voice.google.com), and sets the name to External so I know it's an external call (vs internal):
    exten => youraccount@gmail.com,1,Answer()
    	same => n,Wait(1)
    	same => n,SendDTMF(1)
    	same => n,Set(CALLERID(num)=${CUT(CALLERID(name),@,1)})
    	same => n,Set(CALLERID(name)=External)
The code below check if there is only 1 char in the num (which would mean it's blocked). If yes, then I remove the char to make an empty string, if not I keep it as is. Then the PrivacyManager is called. If there is a caller ID, it does not do anything. If there is none, it will catch it. Finally, I checked the caller id against my blacklist.
    same => n,Set(CALLERID(num)=${IF($[${LEN(${CALLERID(num)})}=1]?:${CALLERID(num)})})
    	same => n,Set(CALLERID(name)=${IF($[${LEN(${CALLERID(num)})}=0]?Anonymous:${CALLERID(name)})})
    	same => n,PrivacyManager()
After that, you can handle the call the way you want. IE: same => n,Dial(...) Posted by simon templar at Feb 03, 2013 20:33
Is it possible to set GV up like any other trunk so that I can take advantage of the DID & CID. In other words, I would like to have a inbound route based on DID and CID info.... If so how would I go about doing that with this setup you have listed above? Thanks aphibian Posted by amphibian at Aug 30, 2013 22:36
Hi! There are Forums, Mailing lists and IRC chat rooms where you could ask that sort of question. It is unlikely to get answered here. Look at http://www.asterisk.org/community for links to all the various resources. Posted by rnewton at Sep 05, 2013 16:20
I don't think ice support is needed any more. I just set up 2 11.5.1 servers without enabling ice in rtp.conf. stun support was enabled. And motif worked. Posted by seandarcy at Sep 23, 2013 20:12
I'm having a heck of a time with this using 11.6.0. I have set icesupport=yes in both rtp.conf and sip.conf (where it also exists in the sample file) and set the stunaddr to a wide variety of servers from various public lists. Here's what I get with "stun show status" CLI> stun show status Hostname Port Period Retries Status ExternAddr ExternPort (null) 0 30 3 INIT 0.0.0.0 0 Everything else seems to be working; if I call my GV number from my cell phone here's what I see: [Oct 24 15:18:41] ERROR[2866]: chan_motif.c:2035 jingle_interpret_google_transport: Received Google transport information on session 'SIP1883622057@10.229.193.197' but ICE support not available Google hasn't been any help on this. I set "stun set debug on" but nothing, NOTHING shows up at any time. I'm stuck and don't know where to turn (yes, punny). Posted by capouch at Oct 24, 2013 14:20
res_rtp_asterisk uses the pjproject library for ICE/STUN/TURN support and local address discovery. This library has a dependency on libuuid-dev on some systems and in previous versions of Asterisk was a hard dependency. Due to community feedback this dependency was made optional, thus making pjproject building optional. I'd suggest installing the libuuid-dev package, or the equivalent within your distribution, rerunning the Asterisk configure script, and rebuilding Asterisk. This should build it with ICE support. Posted by jcolp at Oct 24, 2013 14:47
It looks like it found libuuid and the headers, etc., originally, but I fetched the sources and built the latest (uuid-1.6.2) sources. Reconfigured Asterisk --with-uuid, but the make didn't build anything new. Is the pjproject library part of the Asterisk source? stun show status didn't change, so I don't think I'm there yet. Am I correct that if ICE is enabled and up that should show something other than a "null" hostname? Posted by capouch at Oct 24, 2013 15:11
It's bundled with Asterisk. The "stun show status" command is for the internal STUN functionality outside of res_rtp_asterisk. Posted by jcolp at Oct 24, 2013 15:14
Sorry for my thread-nesting gaffe a minuteago. How can I tell if the proper libraries (particularly pjproject) are built and installed? I'm sort of flying blind in terms of being able to discover what I'm doing wrong. There ain't much out there on this, and I'm sorry to be a bother. The biggest questions right now are: a) How can I determine if the build contains the proper components, and b) how can I tell from the CLI whether they're being invoked? Posted by capouch at Oct 24, 2013 15:18
pjproject is build and embedded into res_rtp_asterisk - not installed as a shared library. If you do a make clean and then make you should see it being built right before res_rtp_asterisk is. There is no real CLI way to know whether it's invoked or not - you just won't get "ICE support not available" when it's used by chan_motif. Posted by jcolp at Oct 24, 2013 15:20
Still no joy: I have uuid libs (old and new) installed --with-uuid in Asterisk configure But the code in ~res/pjproject remains unbuilt: [CC] res_config_curl.c -> res_config_curl.o [LD] res_config_curl.o -> res_config_curl.so [CC] res_rtp_asterisk.c -> res_rtp_asterisk.o [LD] res_rtp_asterisk.o -> res_rtp_asterisk.so And it also looks like the configure scripts found the uuid libs. From config.log: configure:28481: checking for uuid_generate_random in -luuid configure:28506: gcc -o conftest -g -O2 conftest.c -luuid -lm >&5 configure:28540: checking uuid/uuid.h usability configure:28540: checking uuid/uuid.h presence configure:28540: checking for uuid/uuid.h ac_cv_header_uuid_uuid_h=yes ac_cv_lib_uuid_uuid_generate_random=yes UUID_LIB=' -luuid ' Not sure where to go next–perhaps something I'm missing in menuselect? Posted by capouch at Oct 24, 2013 15:31
I got nothin' Posted by jcolp at Oct 24, 2013 15:32
One last hope: do you know what in particular triggers the building of the pjproject code? I know I can't just go in there and do it manually. . . . Posted by capouch at Oct 24, 2013 15:39
Capouch why are you using both icesupport and stun? Although mine is setup a little differently than what is listed above I have no issues using GV numbers (5 of them) with Version 11.04 just having icesupport=yes within rtp.conf. There is no need to add it within sip.conf and don't see a need for stun. Posted by amphibian at Oct 25, 2013 00:05
I just upgraded to 11.6 from 11.4 and can't get Google dialing working either... I get "Unable to add Google ICE candidates as ICE support not available or no candidates available"... no luck with 12 beta either... Guess I'm stuck on 11.4 for a while yet. Posted by bromont at Oct 25, 2013 14:31
Actually after having hassling several times getting the pjproject libraries to build, I ditched 11.6 and started with a fresh VM instance, then installed the pjproject code (from the github sources). I configured it using the same configuration as I found in the Asterisk source tree in the Makefile in the ~/res directory. I had to add --withouts for video and v4l2 to get it to build. Once I completed that I did a fresh install of Asterisk 12.0.0-beta1, and now have a working (albeit with some WebSockets bugs) version now talking to Google Voice just fine. I think the Asterisk configure scripts will let it build it without warnings or errors even if you don't build pjproject as shared libraries, but then it crashes in odd and mysterious ways. From the best I can tell, that's what was plaguing my earlier V12-beta build attempts. Posted by capouch at Oct 25, 2013 15:19
Thanks capouch, pjproject was the dependencies that I was missing to fix the "Unable to add Google ICE candidates as ICE support not available or no candidates available" . Been trying to figure this out for about 2 weeks now that I was able to compile asterisk with pjproject support, everything seems smooth.. Few outgoing call issues with dropped calls after 5 seconds, but i'll probably figure that one out here soon Posted by dmt010 at Nov 06, 2013 12:03
I am seeing that too, if you mean: totally normal conversation for ~5 seconds, then suddenly a fatal error report (transmission limit exceeded, IIRC) on the CLI, and then call is torn down, even though the two parties were having a swimmingly good, clear, conversation. . Posted by capouch at Nov 06, 2013 16:09