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.
- That calls will terminate to or originate from the incoming-motif context; context=incoming-motif
- That all codecs are first explicitly disallowed
- That G.711 ulaw is allowed
- 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:
- PCMA
- PCMU
- G.722
- GSM
- iLBC
- 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:
- PCMA
- PCMU
- G.722
- iLBC
- Speex 16kHz
- 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.
- The type is set to client, as we're connecting to Google as a service; type=client
- The serverhost is Google's talk server; serverhost=talk.google.com
- Our username is configured as your_google_username@gmail.com; username=your_google_username@gmail.com
- Our password is configured using the secret option; secret=your_google_password
- Google's talk service operates on port 5222; port=5222
- Our priority is set to 25; priority=25
- TLS encryption is required by Google; usetls=yes
- Simple Authentication and Security Layer (SASL) is used by Google; usesasl=yes
- We set a status message so other Google chat users can see that we're an Asterisk server; statusmessage="I am available"
- 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)
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.
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! ![]() |
Done! ![]() |
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. ![]() |
It doesn't expose any channel variables right now, unfortunately. To accomplish what you are referring to you'd have to create separate contexts. ![]() |
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. ![]() |
The Caller ID filtering code doesn't work on certain telephone services: If I call from my home landline, I get one ring, then it hangs up on me. Destination extension never rings. If my friend in CA calls long distance, it works perfectly fine for him. 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) ![]() |
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. ![]() |
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 ![]() |
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. ![]() |
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. ![]() |
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 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).
![]() |
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. ![]() |
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? ![]() |
It's bundled with Asterisk. The "stun show status" command is for the internal STUN functionality outside of res_rtp_asterisk. ![]() |
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? ![]() |
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. ![]() |
Still no joy:
But the code in ~res/pjproject remains unbuilt: [CC] res_config_curl.c -> res_config_curl.o And it also looks like the configure scripts found the uuid libs. From config.log: configure:28481: checking for uuid_generate_random in -luuid Not sure where to go next–perhaps something I'm missing in menuselect? ![]() |
I got nothin' ![]() |
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. . . . ![]() |
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.
![]() |
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. ![]() |
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. ![]() |
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 ![]() |
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. . ![]() |