GVoice In Flames No More

Hi Ward:
Sorry for the cross-talk of our posts - when I read Malcolm's request for a Jabber debug log file, my excitement of understanding what someone was speaking about got the better of me and I rushed off to see if I could help nline2longb:
I'll try your solution now and see if it works

You would not want to do that, because then you will have problems if another call comes in.

If you are on a call, and someone calls in via google voice, and you flash over, it gives you an option to 1 - accept call as a new call 2- join the conversation, 3 - ignore (I maybe wrong about the exact choices, its been over a year since I heard them).

So you need to have the system pressing dtmf 1, or else the second call will not be able to hit an ivr or anything.

I will point out that if someone has a DID (free or otherwise) in addition to a Google Voice number, there's a poor workaround that avoids the eight second wait (assuming that works for you). What you have to do is this:

1. Go into Google Voice configuration and have it send calls to your DID only (uncheck Google Chat. You may have to add your DID as a destination).
2. In extensions_custom.conf, comment out the three lines that answer the call, wait for one second (or eight seconds if you tried the above fix), and send the DTMF 1.
3. Go into your Inbound Routes and set your DID to go to your desired extension. Optionally, then set your Google Voice number to go to Terminate Call: Play ringtones to caller until they hangup (this should make no difference if you unchecked Google Chat as a destination).
4. Do an orange bar reload in FreePBX.

What will happen is Google Voice send the call to your DID. The DID does NOT ignore your instruction to disable call screening, so it goes right through and connects as soon as you pick up the extension. It also costs Google money in termination charges, so maybe if enough people do this it will finally motivate them to fix the issue where the call screening disable option is being ignored in a case where the destination is Google Chat, since nothing else seems to motivate them to fix that bug!

(As you may have noticed, I'm not feeling too charitable toward Ggle today).

(Edited after seeing twack1's comment to reflect that you don't need to leave Google Chat selected as a destination in order to place outgoing calls).

Maybe I'm missing something here, but how do you "flash over" when using an Asterisk extension? This does not sound like any behavior I've ever encountered, nor anything I would want.

Seriously, I DO want Google to honor the "Disable Call Screening" setting if that's what I've selected. Of course you would always have the option to not select that, if you don't want it. But I think that for many of of us, it would remove a major cause of issues with Google Voice, if they would just honor their setting!

If only we had an e-mail address for someone in the company, where the mail actually gets read and responded to.

I have posted about this issue before in one of their Google Voice support forums. I might as well have used that time to watch paint dry, for all the good it did. Google is the epitome of a huge, unresponsive behemoth, in my personal opinion and experience.

But, Malcolm, maybe if you wrote them they would listen — your name probably (hopefully) would be recognized by someone there, if only that person ever got to see your e-mail.

If you ever want a real exercise in frustration, try calling Google to report an issue. Apparently there is no one there even capable of taking a phone message. There is a live person that answers the phone, but apparently (unless maybe you are one of their big advertisers or a company executive) she can't transfer a call, take a message, or forward information about an issue to the correct department.

Even with Wards' extensions_custom.conf patch, I was still getting "Press 1 for.... and 2 for voicemail" when I picked up an incoming GV call.

As an interim workaround, I forwarded my google voice account to my Sipgate number and unchecked the forward to "Google Chat" in my google voice settings.

Google out still works fine and now inbound calls come through the Sipgate trunks with google voice mail still handling the VM.

I'll leave it this way until the DTMF issue is solved.

--------------------------
Update:

If I up the wait to 10, the DTMF statement works.

MT:
(1) Configuring a Google Voice Account to
[a] forward to BOTH the original DID used to create the Google account
also forward to the Google Chat destination

and then:

(2) Configuring FreePBX to receive both of the calls, seems to my untrained eye to be a bad idea...

Argument:
I may not be able to explain exactly why in technical terms, but I'll give my best attempt
Before today, when dialing an outside line from an extension, (a configured softphone) even if I immediately hung the call up on the extension's end, a call would still be made. For example, let's say I called my cell from the softphone and then ended the call right away. Even though the call was ended on the softphone, a call would still be received on my cell. If I answered the call on my cell, there wouldn't be anything to hear - it would just be dead silence.
There is some term for this, but I can't recall it right now. Something like "non-terminated connections" or something.
At the same time, if I call my cell from another cell, but hang up the calling cell before it starts ringing, the receiving cell would never know that a call was early-termed. (Receiving cell would never ring)
With this in mind, if you follow your instructions, then two things would happen (according to the context of my idea)
1) FreePBX server would receive two calls forwarded from Google for every call.
2) There would be twice the amount of likelihood that something may go wrong with call answering, bridging, monitoring, barging, transferring, terminating, recording, applying codecs to, and so...

The Google Chrome browser has an impressive developer resource site to report bugs and request features:
http://dev.chromium.org/getting-involved/dev-channel

Bugs reported on the dev site are normally responded to in a matter of minutes, and at least for the one bug that I reported, it was resolved in a matter of hours.

However, I couldn't find much info on Google Voice at the Chrome dev site, but I did find this forum that MAY be of some help:

http://www.google.com/support/forum/p/Google Apps/label?lid=32ef84cb144f0e32&hl=en

Although this may be the same site you posted your previous question to and didn't get a good response. The second link seems to have a sharp decline of eggheads than the dev site

I believe this is a combination of delay AND tone length... I have set wait(8) and modified sendDTMF(1) to be sendDTMF(11) applied, amportal restart, and everything seems to have come back online for me. have gotten my IVR ten out of ten tries since the change. Can anyone else confirm this?

Ward:
Your solution worked perfectly. The only real difference now is that instead of incoming callers hearing a ring tone while waiting for an extension to pick up, they are greeted with "Thank you for calling, please wait a moment while I find someone to take your call."

Hey eCase -

I don't think that has anything to do with this issue.. I remember dealing with that many months ago when I first setup PIAF. It was a setting somewhere that played a system recording instead or directly ringing.. I don't remember where I changed mine..

I think it will be different depending on what destination you have set for your incoming routes. I think it will be listed under Announcement.. and you will see something like "please-wait-connect-on-call-eng" (something along those lines). You need to set that to none so it rings directly..

Hope that helps. I can confirm I am not experiencing that.. What is your destination set to?? Ring Group? Extension? etc.?

JP

Hey All,

Haven't been around this forum in awhile.. My PIAF was running too smoothly I guess ..

Anyway, this issue started happening to me on the 20th. I actually have FIVE GV numbers on my PIAF box. All of sudden I was getting a flood of emails from my gmail alert accounts and no incoming calls. I didn't have time to deal with it until today. Frankly I was about to give up on GV after the last debacle back in December.. I came here knowing there would probably be a long post about it..

My system has 5 GV accounts. Each one has an inbound route that uses totally different destinations. One goes to an IVR, one goes to Time Conditions and an IVR, one goes to a ring group, one goes to a direct extension and one goes to an announcement that then goes to the Callback feature as "Destination after playback".. They ALL stopped working and I thought it would be a giant hassle.

All I did to fix it was add one line from Ward's fix to the [googlein] context in my extensions_custom.conf.

I added only this line:

Code:

exten => s,n,Wait(8)

I have extensively tested it today and made 9-10 calls to all my GV DIDs from an outside line. All of them reached their destination without fail..

My setup may be a bit different from others so maybe that is why just that one line is working for me?? I really don't know, but I'm not experiencing any of the other problems in this post or having to modify anything else.

My setup is for multi-tenant PIAF purple, still based exactly on the tutorial I wrote back in December when the last GV problems were happening:

New Multi-Tenant PIAF Purple w/ ALL latest Gtalk fixes! 12/10/2010

The end of my [googlein] context had only 3 lines beginning with/including the regcall Answer line:

Code:

exten => s,n(regcall),Answer
exten => s,n,SendDTMF(1)
exten => s,n,Goto(from-trunk,gv-incoming-${CUT(ALERTNAME,@,1)},1)

I added the one "wait" line and changed it to:

Code:

exten => s,n(regcall),Answer
exten => s,n,Wait(8)
exten => s,n,SendDTMF(1)
exten => s,n,Goto(from-trunk,gv-incoming-${CUT(ALERTNAME,@,1)},1)

That's it.. Everything has worked flawlessly since then.

I don't have, nor have I ever seen, the line:

Code:

;exten => s,n(regcall),Set(DIAL_OPTIONS=${DIAL_OPTIONS}aD(:1 ))

I have not manually modified any of my files since what I described in the link above back in December. Adding this line is the only difference from what I posted in that tutorial. But I did run update-programs, update-fixes and update-source about 2 months back..

My current setup is:

Code:

PBX in a Flash Version     = 1.7.5.5
FreePBX Version             = 2.8.1.2
Running Asterisk Version  = Asterisk 1.8.2.3
Asterisk Source Version    = 1.8.2.3
Dahdi Source Version       = 2.4.0+2.4.0
Libpri Source Version       = 1.4.11.5
IP Address                      = 192.168.0.111 on eth0 
Operating System            = CentOS release 5.5 (Final)
Kernel Version                = 2.6.18-194.17.4.el5 - 32 Bit 

My entire [googlein] context in extensions_custom.conf is:

Code:

[googlein]
exten => account1@gmail.com,1,Wait(1)
exten => account1@gmail.com,n,Set(ALERTNAME=account1@gmail.com)
exten => account1@gmail.com,n,JABBERSend(asterisk,${ALERTNAME},Incoming Google Voice Call: ${CALLERID(name):2:10})
exten => account1@gmail.com,n,Set(CALLERID(number)=${CALLERID(name):2:10})
exten => account1@gmail.com,n,Set(CALLERID(name)=${CALLERID(number)})
exten => account1@gmail.com,n,GotoIf(${DB_EXISTS(gv_dialout_account1/channel)}?bridged)
exten => account1@gmail.com,n,Goto(s,regcall)
exten => account1@gmail.com,n(bridged),Bridge(${DB_DELETE(gv_dialout_account1/channel)})
exten => account2@gmail.com,1,Wait(1)
exten => account2@gmail.com,n,Set(ALERTNAME=account2@gmail.com)
exten => account2@gmail.com,n,JABBERSend(asterisk2,${ALERTNAME},Incoming Google Voice Call: ${CALLERID(name):2:10})
exten => account2@gmail.com,n,Set(CALLERID(number)=${CALLERID(name):2:10})
exten => account2@gmail.com,n,Set(CALLERID(name)=${CALLERID(number)})
exten => account2@gmail.com,n,GotoIf(${DB_EXISTS(gv_dialout_account2/channel)}?bridged)
exten => account2@gmail.com,n,Goto(s,regcall)
exten => account2@gmail.com,n(bridged),Bridge(${DB_DELETE(gv_dialout_account2/channel)})
exten => account3@gmail.com,1,Wait(1)
exten => account3@gmail.com,n,Set(ALERTNAME=account3@gmail.com)
exten => account3@gmail.com,n,JABBERSend(asterisk3,${ALERTNAME},Incoming Google Voice Call: ${CALLERID(name):2:10})
exten => account3@gmail.com,n,Set(CALLERID(number)=${CALLERID(name):2:10})
exten => account3@gmail.com,n,Set(CALLERID(name)=${CALLERID(number)})
exten => account3@gmail.com,n,GotoIf(${DB_EXISTS(gv_dialout_account3/channel)}?bridged)
exten => account3@gmail.com,n,Goto(s,regcall)
exten => account3@gmail.com,n(bridged),Bridge(${DB_DELETE(gv_dialout_account3/channel)})
exten => account4@gmail.com,1,Wait(1)
exten => account4@gmail.com,n,Set(ALERTNAME=account4@gmail.com)
exten => account4@gmail.com,n,JABBERSend(asterisk4,${ALERTNAME},Incoming Google Voice Call: ${CALLERID(name):2:10})
exten => account4@gmail.com,n,Set(CALLERID(number)=${CALLERID(name):2:10})
exten => account4@gmail.com,n,Set(CALLERID(name)=${CALLERID(number)})
exten => account4@gmail.com,n,GotoIf(${DB_EXISTS(gv_dialout_account4/channel)}?bridged)
exten => account4@gmail.com,n,Goto(s,regcall)
exten => account4@gmail.com,n(bridged),Bridge(${DB_DELETE(gv_dialout_account4/channel)})
exten => account5@gmail.com,1,Wait(1)
exten => account5@gmail.com,n,Set(ALERTNAME=account5@gmail.com)
exten => account5@gmail.com,n,JABBERSend(asterisk5,${ALERTNAME},Incoming Google Voice Call: ${CALLERID(name):2:10})
exten => account5@gmail.com,n,Set(CALLERID(number)=${CALLERID(name):2:10})
exten => account5@gmail.com,n,Set(CALLERID(name)=${CALLERID(number)})
exten => account5@gmail.com,n,GotoIf(${DB_EXISTS(gv_dialout_account5/channel)}?bridged)
exten => account5@gmail.com,n,Goto(s,regcall)
exten => account5@gmail.com,n(bridged),Bridge(${DB_DELETE(gv_dialout_account5/channel)})
exten => s,1,Wait(1)
exten => s,n,Set(ALERTNAME=icreationspbx@gmail.com)
;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
exten => s,n,Wait(8)
exten => s,n,SendDTMF(1)
exten => s,n,Goto(from-trunk,gv-incoming-${CUT(ALERTNAME,@,1)},1)

I have NO idea why everything is working fine for me with only adding the wait line, but hopefully someone that knows a lot more about this can use this information to help out..

Take care!
JP

When using the 'no reply config' to keep using the gl voicemail, it looks like changing to Set(DIAL_OPTIONS=${DIAL_OPTIONS}aDwwwwwwwwwwwwww1)) is working ok.

We will need to fill the dead air of the called party with some tones or prompt, but this looks ok.