Skip to end of metadata
Go to start of metadata


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


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.


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


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 -

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

[email protected]
statusmessage="I am available"

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;
  3. Our username is configured as [email protected]; [email protected]
  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:


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:

exten => s,1,NoOp()
 same => n,Wait(1)
 same => n,Answer()
 same => n,SendDTMF(1)
 same => n,Dial(SIP/malcolm,20)

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


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.

Filtering Caller ID


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

[email protected]/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/[email protected],,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},,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.

  • No labels


  1. Can you clarify which configuration file the icesupport=yes directive belongs in? Thanks!

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

    1. It doesn't expose any channel variables right now, unfortunately. To accomplish what you are referring to you'd have to create separate contexts.

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

  3. 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:

  4. 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 [email protected]

    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 , 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 ([email protected]), and sets the name to External so I know it's an external call (vs internal):

    exten => [email protected],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(...)

  5. 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?




    1. 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 for links to all the various resources.

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

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

    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 '[email protected]' 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).



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

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



  8. 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?

    1. It's bundled with Asterisk. The "stun show status" command is for the internal STUN functionality outside of res_rtp_asterisk.

      1. 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?

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

          1. 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 ->
            [CC] res_rtp_asterisk.c -> res_rtp_asterisk.o
            [LD] res_rtp_asterisk.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
            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
            UUID_LIB=' -luuid '

            Not sure where to go next–perhaps something I'm missing in menuselect?

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

                1. I was getting exactly the same ICE issues with a build of Asterisk 11.7 on Ubuntu 12.04. It seems that pjproject is not building as part of the make for 11.7. I compiled 11.4, and it ran first time, without any changes to sip.conf or rtp.conf.

                  I was upgrading from 1.8 to 11.7. I wonder if the issue only affects people going straight into 11.6/11.7, and not people moving up from prior 11.x versions?

                  It feels like this is a compile bug. I'm not sure whether it's worth raising upstream at the moment, given that pjproject is more clearly separated from the build process from 12 onwards.


                  1. Nick, please take a look at Asterisk Issue Guidelines and then file an issue on .

                    The issue will not get attention here in the comments of a wiki page.

                    If you are looking to see if others are having the same issue, then a better place to post would be on the users mailing list. However if what you are saying is correct and easily reproduceable, it is better to go ahead and file a bug so we can look into it. Thanks!

                    1. Although I haven't seen the config log, this most likely isn't a bug.

                      You need to make sure you have libuuid (and the development version) installed; otherwise, pjproject won't be enabled in Asterisk 11. That's on purpose; without libuuid, certain parts of pjproject won't function correctly. Checks were placed in Asterisk 11 to make sure that it was available to avoid other more serious problems.

                      1. I checked through all the points made by previous posters. I do have libuuid and libuuid-dev installed, it was detected during configuration, and the right flags are being added to the compiler. I can manually compile pjproject just fine from within res/ , it just doesn't appear to being picked up in the build of asterisk.

                        Rusty - thanks for the advice, and I'll post this experience to the user list. I wanted to add something here as it was one of the most relevant page hits on Google search when I was hunting for a solution to the problem.

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

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

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

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

          1. I've seeing that now with 12.3.2. I don't even get any errors on the CLI.

            Did you ever find a solution?

  10.  I installed Asterisk 11.7.0.    But getting following errors with GTALK


    Error while trying to call using GTalk (Outgoing through google)

    chan_motif.c:821 jingle_add_google_candidates_to_transport: Unable to add Google ICE candidates as ICE support not available or no candidates available


    Error while incoming 

    chan_motif.c:2035 jingle_interpret_google_transport: Received Google transport information on session '[email protected]' but ICE support not available

    1. You need to enable ICE. See the "RTP Configuration" section on this page.

      1. I did samething....   Here is my rtp.conf details

        ; RTP start and RTP end configure start and end addresses
        ; Defaults are rtpstart=5000 and rtpend=31000

  11. I followed these instructions and it's almost working. Certainly test calls from within my own LAN are working fine.

    Incoming calls from my tame correspondent who is using Mo+ don't get answered. Not sure if this is a NAT or codec problem until I've done more investigation.

    Anyway, the point of this post is to say that in xmpp.conf line:

    statusmessage="I am available"

    the quotes aren't necessary. If they are included, they show up in the displayed status.


  12. i have a trouble with asterisk 13 & google voice the ni call out .

    here is the error that i have 

    == Using SIP RTP CoS mark 5
    -- Executing [[email protected]:1] Dial("SIP/103-00000046", "Motif/xxxxgmailcom/[email protected],,r") in new stack
    -- Called Motif/[email protected]/[email protected]
    -- Motif/[email protected] is proceeding passing it to SIP/103-00000046
    -- No one is available to answer at this time (1:0/0/0)
    -- Auto fallthrough, channel 'SIP/103-00000046' status is 'NOANSWER'

    can u help ? 



    1. Looks like the failure is on the SIP channel side. However you should ask this type of question on and not here on the wiki.