GVoice In Flames No More

[gvtricks]

This is the way I have solved my hit and miss problem with GV incoming:

1)I got a free DID number from Ipcomms.net.
2)I add this number to my dedicated GVoice account for PIAF.
3)untick Google chat forwarding calls on your GVoice account (this is very important
because you don't want to have two numbers forwarding to your PBX Box)
4)Tick your Ipcomms to be the forwarding number to your PBX.

Believed or not your Outgoing calls will go out using the gvoice setup (Google Chat)

There are No delays In incoming calls when dialing your GV number. It is also a good
way to get free faxes using your GVoice number.
I have no problems for outbound calls on my GV

5)Create a trunk and an inbound Route for your IPcomms DID.
I thing this will also work with sipgate and IPKall DIDs.

TRUNK SETUP

Outgoing settings

Trunk Name ipcomms


Incoming Settings

USER Context  3055551212

secret=119XXXXXXX
username=3055551212
host=sipconnect.ipcomms.net
disallow=all
allow=ulaw
context=from-trunk
dtmfmode=rfc2833
insecure=very
nat=yes
type=friend
canreinvite=no


Register String

3055551212:[email protected]/3055551212

INBOUND ROUTE SETUP

Sorry my bad yes it is the inbound route for Ipcomms:

Description  Ipcomms

DID Number: 3053059792


Detect Faxes: yes

Fax Detection type: Sip

Fax Detection Time: 4

Fax Destination: Custom Destination Fax(Hylafax)

[B]Set Destination[/B]


Day Night Mode  (1)Code1

Gvtricks

 

[Fala]

This is the way I have solved my hit and miss problem with GV incoming:

1)I got a free DID number from Ipcomms.net.
2)I add this number to my dedicated GVoice account for PIAF.
3)untick Google chat forwarding calls on your GVoice account (this is very important
because you don't want to have two numbers forwarding to your PBX Box)
4)Tick your Ipcomms to be the forwarding number to your PBX.

Believed or not your Outgoing calls will go out using the gvoice setup (Google Chat)

There are No delays In incoming calls when dialing your GV number. It is also a good
way to get free faxes using your GVoice number.
I have no problems for outbound calls on my GV

5)Create a trunk and an inbound Route for your IPcomms DID.
I thing this will also work with sipgate and IPKall DIDs.

TRUNK SETUP

Outgoing settings

Trunk Name ipcomms


Incoming Settings

USER Context  3055551212

secret=119XXXXXXX
username=3055551212
host=sipconnect.ipcomms.net
disallow=all
allow=ulaw
context=from-trunk
dtmfmode=rfc2833
insecure=very
nat=yes
type=friend
canreinvite=no


Register String

3055551212:[email protected]/3055551212

OUTBOUND ROUTE SETUP

Description  Ipcomms

DID Number  3055551212


Set Destination

Day Night Mode    (1)Code1

Gvtricks

I'm still having problems getting incoming Fax to work with my GV Number and Ipcomms combination. In the above, it shows "OUTBOUND ROUTE SETUP"; shouldn't that be INBOUND instead of OUTBOUND? Also, under Incoming Route for IPcomms, should the "Detect Faxes" be set to yes, with SIP, etc. selected? For some reason, the calls are being answered by my GV voice mail following your procedure above. Any suggestion to make this work?

 

[gvtricks]

I'm still having problems getting incoming Fax to work with my GV Number and Ipcomms combination. In the above, it shows "OUTBOUND ROUTE SETUP"; shouldn't that be INBOUND instead of OUTBOUND? Also, under Incoming Route for IPcomms, should the "Detect Faxes" be set to yes, with SIP, etc. selected? For some reason, the calls are being answered by my GV voice mail following your procedure above. Any suggestion to make this work?

Sorry my bad yes it is the inbound route for Ipcomms:

Description Ipcomms

DID Number: 3053059792


Detect Faxes: yes

Fax Detection type: Sip

Fax Detection Time: 4

Fax Destination: Custom Destination Fax(Hylafax)

Set Destination


Day Night Mode (1)Code1

 

[zaazz]

I re-installed the newest PIAF-purple - Asterisk 1.8.4.1. I've been having a lot of problems with inbound calls. After the fresh reload I could get 1 inbound to ring at my phones internally. After that they all went to Google VM. I thought had done something wrong so I reloaded the box again. On the 3rd time I went to the forums, heh.

I saw this thread and extended my wait to 12 seconds as you can see below. Now calls seem to come in every time. I wish I knew more about linux and asterisk so that I could understand this better but I assume there's some kind of delay between my box and google, but why? Anyone able to explain this to a novice?

[googlein]
exten => [email protected],1,Wait(1)
exten => [email protected],n,Set([email protected])
exten => [email protected],n,JABBERSend(asterisk,${ALERTNAME},Incoming Google Voice Call: ${CALLERID(name):2:10})
exten => [email protected],n,Set(CALLERID(number)=${CALLERID(name):2:10})
exten => [email protected],n,Set(CALLERID(name)=${CALLERID(number)})
exten => [email protected],n,GotoIf(${DB_EXISTS(gv_dialout_freetrult1121/channel)}?bridged)
exten => [email protected],n,Goto(s,regcall)
exten => [email protected],n(bridged),Bridge(${DB_DELETE(gv_dialout_freetrult1121/channel)}, p)
exten => s,1,Wait(1)
exten => s,n,Set([email protected])
;exten => _X.,n,Set(STATUS=${JABBER_STATUS(asterisk,${ALERTNAME})});
;exten => _X.,n,NoOp(Gvoice/Jabber Status: ${STATUS})
exten => s,n,JABBERSend(asterisk,${ALERTNAME},Incoming Google Voice Call: ${CALLERID(name):2:10})
exten => s,n,Set(CALLERID(number)=${CALLERID(name):2:10})
exten => s,n,Set(CALLERID(name)=${CALLERID(number)})
exten => s,n(regcall),Answer
[COLOR="Red"]exten => s,n,Wait(12)[/COLOR]
exten => s,n,SendDTMF(11)
;exten => s,n(regcall),Set(DIAL_OPTIONS=${DIAL_OPTIONS}aD(:1 ))
exten => s,n,Goto(from-trunk,gv-incoming,1)

──────────────────System Information───────────────────────────┐
   │  Asterisk   = ONLINE  | Dahdi     = ONLINE  | MySQL     = ONLINE    │
   │  SSH        = ONLINE  | Apache    = ONLINE  | Iptables  = ONLINE    │
   │  Fail2ban   = ONLINE  | Internet  = ONLINE  | Ip6Tables = ONLINE    │
   │  BlueTooth  = ONLINE  | Hidd      = ONLINE  | NTPD      = ONLINE    │
   │  SendMail   = ONLINE  | Samba     = OFFLINE | Webmin    = ONLINE    │
   │  Ethernet0  = ONLINE  | Ethernet1 = N/A     | Wlan0     = N/A       │
   │                                                                     │
   │  PBX in a Flash Version   = 1.7.5.6                                 │
   │  FreePBX Version          = 2.8.1.4                                 │
   │  Running Asterisk Version = 1.8.4.1                                 │
   │  Asterisk Source Version  = 1.8.4.1                                 │
   │  Dahdi Source Version     = 2.4.1.2+2.4.1                           │
   │  Libpri Source Version    = 1.4.11.5                                │
   │  IP Address               = 192.168.1.55 on eth0                      │
   │  Operating System         = CentOS release 5.6 (Final)              │
   │  Kernel Version           = 2.6.18-238.9.1.el5 - 32 Bit

 

[grillovillegas]

Seems to be that the 2 seconds wait its working back again calls are coming faster now.. thanks ....

 

[kenn10]

Its not the PBX....

I wish I knew more about linux and asterisk so that I could understand this better but I assume there's some kind of delay between my box and google, but why? Anyone able to explain this to a novice?

The delay has nothing to do with the PBX. The delay is introduced by Google Voice. If you were to have Google Voice ring your cell phone for example, you get a message about pressing "1" to accept the call. Sometimes Google Voice delays in playing the recording by a random number of seconds. I believe this is deliberate on the part of Google to block easy PBX integration with their product.

 

[saladman02]

Arrgh. GVoice seems totally unpredictable.

Hello everyone. I can admit to being a newbie to the world of Incredible PBX. The instructions and comments here and on Nerdvittles have been amazing, and made it clear that I need to plan an annual donation.

I’ve run into a problem though, where I rarely receive inbound calls. I’ve tried the “11” in the dial plan, I’ve tried ranging the delay from 1 sec out to 14 seconds. I even gave up on making the g-chat client work for inbound, and bought an Obihai 110, and set it up per the Michigan Telephone Blog instructions.

Now it seems that callers have a 50% chance of being picked up by the IVR, or a 50% chance of being sent to google voicemail.


I’ve included call logs from a successful call, and a failed call. Any chance somebody can give me a hint of where to look for the trouble?

Thanks
S
Call record from an incoming call intercepted by IVR:


[2011-07-21 16:34:03] VERBOSE[16302] func_timeout.c: -- Response timeout set to 14.000
[2011-07-21 16:34:03] VERBOSE[16302] pbx.c: -- Executing [s@ivr-4:11] Set("SIP/1234567890-000000dc", "__IVR_RETVM=") in new stack
[2011-07-21 16:34:03] VERBOSE[16302] pbx.c: -- Executing [s@ivr-4:12] ExecIf("SIP/1234567890-000000dc", "1?Background(custom/MainMenu00)") in new stack
[2011-07-21 16:34:03] VERBOSE[16302] file.c: -- <SIP/1234567890-000000dc> Playing 'custom/MainMenu00.slin' (language 'en')
[2011-07-21 16:34:36] VERBOSE[16302] pbx.c: -- Executing [s@ivr-4:13] WaitExten("SIP/1234567890-000000dc", ",") in new stack
[2011-07-21 16:34:37] VERBOSE[16302] pbx.c: == CDR updated on SIP/1234567890-000000dc
[2011-07-21 16:34:37] WARNING[16302] func_db.c: DB_DELETE requires an argument, DB_DELETE(<family>/<key>)
[2011-07-21 16:34:37] VERBOSE[16302] pbx.c: -- Executing [9@ivr-4:1] NoOp("SIP/1234567890-000000dc", "Deleting: ") in new stack
[2011-07-21 16:34:37] VERBOSE[16302] pbx.c: -- Executing [9@ivr-4:2] Set("SIP/1234567890-000000dc", "__NODEST=") in new stack
[2011-07-21 16:34:37] VERBOSE[16302] pbx.c: -- Executing [9@ivr-4:3] Goto("SIP/1234567890-000000dc", "ext-miscdests,17,1") in new stack
[2011-07-21 16:34:37] VERBOSE[16302] pbx.c: -- Goto (ext-miscdests,17,1)
[2011-07-21 16:34:37] VERBOSE[16302] pbx.c: -- Executing [17@ext-miscdests:1] NoOp("SIP/1234567890-000000dc", "MiscDest: MOH") in new stack
[2011-07-21 16:34:37] VERBOSE[16302] pbx.c: -- Executing [17@ext-miscdests:2] Goto("SIP/1234567890-000000dc", "from-internal,600,1") in new stack
[2011-07-21 16:34:37] VERBOSE[16302] pbx.c: -- Goto (from-internal,600,1)


Call log for a call not intercepted before dropped to google voice:


[2011-07-22 10:40:12] VERBOSE[25981] func_timeout.c: -- Response timeout set to 14.000
[2011-07-22 10:40:12] VERBOSE[25981] pbx.c: -- Executing [s@ivr-4:11] Set("SIP/1234567890-000000df", "__IVR_RETVM=") in new stack
[2011-07-22 10:40:12] VERBOSE[25981] pbx.c: -- Executing [s@ivr-4:12] ExecIf("SIP/1234567890-000000df", "1?Background(custom/MainMenu00)") in new stack
[2011-07-22 10:40:12] VERBOSE[25981] file.c: -- <SIP/1234567890-000000df> Playing 'custom/MainMenu00.slin' (language 'en')
[2011-07-22 10:40:21] VERBOSE[25981] pbx.c: == Spawn extension (ivr-4, s, 12) exited non-zero on 'SIP/1234567890-000000df'
[2011-07-22 10:40:21] VERBOSE[25981] pbx.c: -- Executing [h@ivr-4:1] Hangup("SIP/1234567890-000000df", "") in new stack
[2011-07-22 10:40:21] VERBOSE[25981] pbx.c: == Spawn extension (ivr-4, h, 1) exited non-zero on 'SIP/1234567890-000000df'

 

[MichiganTelephone]

You didn't really mention if these logs were while using the OBi110 to bring in the calls or not, but anyway, it sounds like you are hitting the problem I mentioned in my earlier post in this thread (scroll up or go back a page and look for my post dated 04-30-11). The problem is, once the call comes in and Asterisk detects ringing, you can't just answer that exact instant, because exactly what you're describing can occur. And since you are sending the calls to an IVR (which answers the call immediately), that's exactly what happens.

The question I would have is, if you configure the device in the normal way, using a phone plugged into the PHONE port to make and receive Google Voice calls, do incoming calls always work reliably? If so, then it's almost certain that when you route the Google Voice calls to your Asterisk box you are answering them too quickly. Remember the OBi110 should be sending the DTMF 1, not Asterisk.

To delay answering, go to your Inbound Route and set the "Pause Before Answer" setting to 1 or 2.

What should then happen is when the incoming call hits the system, it waits an extra second or two before answering the call. This gives Google Voice time to stabilize and then sends the call to the IVR, where it is answered. Give that a try and see if it fixes the problem.

 

[bobparker]

So editing /etc/asterisk/extensions_custom.conf

and

To delay answering, go to your Inbound Route and set the "Pause Before Answer" setting to 1 or 2.

Achieve the same result?

So if wait in extensions_custom.conf is 8 and Pause before answering is 2, total wait would be 10 or do they mirror each other?

 

[MichiganTelephone]

So editing /etc/asterisk/extensions_custom.conf

and

To delay answering, go to your Inbound Route and set the "Pause Before Answer" setting to 1 or 2.

Achieve the same result?

So if wait in extensions_custom.conf is 8 and Pause before answering is 2, total wait would be 10 or do they mirror each other?

Sorry if that was unclear. My suggestion for the "Pause Before Answer" of 1 or 2 applies ONLY if you are sending Google Voice calls to a DID, and then that DID goes to your Asterisk box (with the exception of the discussion above regarding an Obihai adapter, and that kind of falls into a gray area because the "Pause Before Answer" might help and it might not, but my bet is that it will). Personally, I currently consider these (using a DID or an Obihai device) the only mostly reliable ways to receive calls from Google Voice. It used to bother me that using a DID cost Google money, but my attitude toward Google in general is now :single fuckb: (it's because of Google+ and if you want to know why you can read my blog, but it's not germane to this topic), and truthfully I just find I have far fewer problems when using a DID as an intermediary rather than Google Chat. If you are using a DID, you don't need that particular custom context because your calls come in over a regular FreePBX trunk and you use an Inbound Route to direct them where you want them to go, thus the need to use the "Pause Before Answer" setting to introduce the delay.

But if you are using Google Chat as the vehicle to bring the calls to your PBX, and you are NOT using the Google Voice module (which you probably won't be if you started using Google Voice before that module became available) then you probably will be using a custom context to bring the calls in, and then it makes more sense to include any necessary wait in there.

But, and again this is just a personal thing with me, I really hate to make callers wait ANY amount of time because most callers don't have a lot of patience these days. When I was a kid, the phone company used to tell people to allow ten rings to give the called party time to answer the phone, although in practice most people gave up after six or seven. Today many people are a lot more impatient, and if you hit them with an additional eight second delay before ringing even commences on your system, you will find you lose a lot of calls, because people will have given up by the time the called party has heard only one or two rings! I'm not telling anyone else how to run their system, but personally I wouldn't even use Google Voice for inbound calls if I had to introduce an eight second delay!

So, in order of preference, my choices for bringing in incoming Google Voice calls would be:

1. Send calls from Google Voice to a DID, then use the "Pause Before Answer" setting in the Inbound Route to delay before answering if necessary (or, alternately, use an Obihai adapter as a "gateway" to and from GV — that's actually probably the most reliable way at the moment).
2. Use the new Google Voice module (latest revision only, please) and let that do your configuration for you. You'll be sending calls to Google Chat, but for whatever reason people who use this module SEEM to have fewer issues. However, this may not be a viable option if you're already using another method.
3. One of the older methods, where you would put your wait in extensions_custom.conf. But I'd sure try to get by with something less than an 8 second wait, and I don't really consider this method all that reliable anymore.

Remember, all of the above is just my personal opinion. And note that you can use a DID for your incoming calls even if you are using the Google Voice module (or an older method) to set up your outgoing GV calls — you just have to configure Google Voice to send incoming calls to the DID, and not to Google Chat.

 

[bobparker]

Thank you. That cleared everything up for me.

Set up sipgate again as a trunk and added that number to gvoice along with chat. Calls are getting to my IVR system after one ring instead of 2-3 and sometimes never.

Hopefully this solution provides better reliability for incoming calls.

 

[MichiganTelephone]

Someone just posted a short comment in my blog asking about this patch:

Summary: Workaround for Google Talk protocol change
https://reviewboard.asterisk.org/r/1312/

This is the first I've heard of it, but in checking I do know that these patches were not in Asterisk 1.8.5.0, however the changelog for Asterisk 1.8.6.0-rc1 version shows this, which seems to be a newer version of the same thing (it's by the same submitter, and refers back to the same issue page):

2011-07-11 19:41 +0000 [r327682] Terry Wilson <[email protected]>

* include/asterisk/jingle.h, channels/chan_gtalk.c: Update
chan_gtalk to work with changed GMail-based calls The messages
sent by the GMail client have changed, but include the old-style
messages as well. This patch checks for this case and uses the
old-style offer. (closes issue ASTERISK-18084) Review:
https://reviewboard.asterisk.org/r/1312/

It's much too late for me to attempt an upgrade without serious risk of mucking something up, even if I did want to put a working system at risk (which I don't, particularly), but I'll just say there's a POSSIBILITY (and I want to emphasize that it's ONLY a POSSIBILITY at this point) that upgrading to Asterisk 1.8.6.0-rc1 (that's a download link!) MIGHT fix some of the issues we've been having with incoming Google Voice calls. So, who wants to be the guinea pig, keeping in mind that you'd be testing a beta version of Asterisk?
:beta1b:

 

[MichiganTelephone]

Just when you thought there weren't any new ways for Google Voice to mess with us...

Ever been talking to someone using Google Voice and out of the blue, for no apparent reason, you (and the person you are talking to) hear an announcement that your call is being recorded?

Here's the reason and the fix. And the good news is that the fix just might also help if you've been unable to use touch tones to access certain services or IVR's!

Google Voice finds another way to screw with (some) Asterisk users

 

[wardmundy]

 

[mark847]

My problem with gvoice is that you can not log into the account. Try this from centos command line:
gvoice
email: xxxx
password: xxxx
It fails everytime. So I am pretty sure that this is not a wait problem. Also, at first this still worked on my system, but not my friends. But after a day it now does not work on my system either. So it this new system filtering through the google empire? Can someone please try gvoice from the command line? Thanks.

 

[wardmundy]

It appears that Google may now be using ports other than 5222 for Google Voice calls. We've seen some inbound call failures where a person calls the GV number, and it just continues to ring after you attempt to answer the call. The solution that worked for us was to add the Google server IP address to the permit list in /etc/sysconfig/iptables and restart it:

-A INPUT -s 74.125.92.125 -j ACCEPT

 

[gvtricks]

The authentication process at Google's end changed to involve a server on a different domain, "accounts.google.com".
I don't know if this will be of any meaning for asterisk.If that is the case IMO the IP should be "74.125.67.84"

Gvtricks

 

[wardmundy]

Good tip. Certainly won't hurt to add it to iptables.

We also have found that adding back in the priority=1 line in each of your GV contexts in /etc/asterisk/jabber.conf seems to stabilize the inbound calling. Could just be a fluke, but it kept our line working overnight which is a first at least with Chicago VPS.

 

[wardmundy]

The missing priority=1 is definitely causing the problem at least for inbound calls on some VM machines. Haven't tested elsewhere yet. Here's a patch to fix the GV module.

Log in as root and issue the following command. Running it multiple times is harmless because it won't find the existing string to fix any more.

sed -i 's|port=5222\\nu|port=5222\\npriority=1\\nu|' /var/www/html/admin/modules/googlevoice/functions.inc.php

NOTE: This will only patch Google Voice additions AFTER the patch is applied. If you want to delete and re-add the accounts, that would work, or you can manually make the changes in /etc/asterisk/jabber.conf and restart Asterisk. New Incredible PBX 2 installs after 8 p.m. EDT tonight already have the patch applied.

 

[donnib]

It appears that Google may now be using ports other than 5222 for Google Voice calls. We've seen some inbound call failures where a person calls the GV number, and it just continues to ring after you attempt to answer the call. The solution that worked for us was to add the Google server IP address to the permit list in /etc/sysconfig/iptables and restart it:

I am testing my Google Voice reliability by calling from one Google voice account to another and i see often that the server picks up the call but the call still keeps on ringing from the caller. This matched your description. I tried to add the 74.125.92.125 ip in the Webmin linux firewall as ACCEPT any traffic from this IP but i still see the problem. Not sure if i have added this correct. Any ideas ?