GVoice In Flames No More

[johnnypuffs]

Thanks for the clarification!

I mentioned that file because I don't see it in any of my extensions_custom.conf (even backups before I changed to the multi-tenant setup).. I just wanted to document any differences I saw in my setup since the fix was easy for me and people are having difficulties..

I also think a lot of people are jumping into VOIP with no linux/unix experience so commenting out isn't obvious to them..

Quick question.. I've wondered this for a while but never quite figured it out.. Is Google TRYING to break gvoice for people using asterisk or are these simply "upgrade" on their part that just happen to screw us all..

Best,
JP

The Wait line before SendDTMF(1) is all you need unless you experience a DTMF issue in which case changing SendDTMF(1) to SendDTMF(11) seems to fix it. Thanks, ghurty, for the fix!!!

Some folks had earlier releases with the commented out line so it was left in for clarity. It's commented out with a semicolon so it obviously doesn't do anything.

 

[completetech]

jsut to clarify I should have something liek this at the end of my
[googlein]

exten => [email protected],n,GotoIf(${DB_EXISTS(gv_dialout_gmailid/channel)}?bridged)
;exten => [email protected],n,Goto(s,regcall)
;exten => [email protected],n(bridged),Bridge(${DB_DELETE(gv_dialout_mygmailid/channel)}, p)
exten => s,n(regcall),Answer
exten => s,n,Wait(8)
exten => s,n,SendDTMF(1)
;exten => s,n(regcall),Set(DIAL_OPTIONS=${DIAL_OPTIONS}aD1 ))
exten => s,n,Goto(from-trunk,gv-incoming,1)

 

[MichiganTelephone]

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

Actually I wasn't fond of the idea myself but it was just a case of wanting to get it working any way possible (especially one that doesn't involve adding waits), and I posted after finding a way that works. But now I've edited that post so it no longer does that. The fact that I've been feeling a bit under the weather the past couple of days hasn't helped my thinking process much, I'm afraid.

 

[ghurty]

Has anyone else noticed an increased delay in the connect time for an outbound call to ring?

 

[MisterQ]

I must be missing something - I thought I was running the "latest" - yet the tail-end of my [googlein] ccontext loofs more like.

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,SendDTMF(1)
exten => s,n,Goto(from-trunk,gv-incoming,1)

 

[reconwireless]

I must be missing something - I thought I was running the "latest" - yet the tail-end of my [googlein] ccontext loofs more like.

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,SendDTMF(1)
exten => s,n,Goto(from-trunk,gv-incoming,1)

exten => s,n(regcall),Answer
exten => s,n,Wait(8)
exten => s,n,SendDTMF(1)

My config already had a 2 second wait in it ,I believe I manually built off the origianal rentpbx multitenant gv config... add the "wait" command to your system and you should be golden until the next google update.

 

[eCase]

Has anyone else noticed an increased delay in the connect time for an outbound call to ring?

YES!!!
However, using different softphones will result in different ('lag') predial wait times - that is, if you are using softphones. If you're using hardphones, I couldn't say.
'lag' or 'predial wait times' I define as the time it takes for the called outside phone to ring - I'm utterly unsure if this is industry standard vocabulary

The two softphones that I have compared are:

3CX {Free version} average lag time: 15 seconds
X-lite 4 {Free version} average lag time: 10 seconds

I have no idea what the cause of this is, but I am determined to find an answer

I just came across a link containing info on many types of ip phones - both hardphones and softphones: http://www.voip-info.org/wiki/view/VOIP+Phones
I will post my testing results under a different thread.

 

[completetech]

is google incomming not working for anyone else? looks like as of late yesterday afternoon

 

[jack5225]

yea, there's been something really funky going on with GV for the past two days... since this morning, i can no longer call out, all i get now is "all circuits are busy, please try again later". not sure whats up.

as for the incoming GV chat call screening... for the meantime, until i can get into the .conf files for the above google chat fix, i forwarded my GV to my sipgate account and incoming is working fine now.

 

[wardmundy]

Ours are still working in several different locations.

 

[johnnypuffs]

Ours are still working in several different locations.

Ditto.. Both incoming and outgoing working fine..

Though, I also have noticed a slight delay before outgoing calls start ringing. Not long enough to be a problem, but a difference from how it was.

Question: Has there ever been a problem with GV incoming when setup the "old way" ie..( to forward to a SIPgate DID)?

I really just want a reliable system. I'm trying to figure out here why I'm wasting my time dealing with these GV problems once every month or so.

I have my SIPgate DIDs. What, if any, is the disadvantage of using the SIPgatge method for incoming calls ONLY. Correct me if I'm wrong, but it seems like the most reliable way to go:

Unlimited free inbound with SIPgate.
No GV workarounds to deal with every time GV "breaks".

I only had my system setup this way for a short time before the direct GV methods were implemented. I don't remember any downfall to the incoming calls.. It was the dial back on outbound that was the PIA.

My thinking now for my setup is:

1. GV DIDs setup to forward to SIPgate DIDs for incoming only.

2. Continue to use the "new" GV outgoing method for free outgoing calls.

3. Keep all my GV outgoing trunks listed first in the Trunk Sequences.

4. Have my Vitelity outbound trunks listed last in the Trunk Sequences.

No worries about GV incoming going bonkers on me anymore. Still continue to benefit from free outgoing GV. In the event that GV outgoing gets funky again my Vitelity trunks will kick in and my outgoing calls will still go through.

Am I missing something here or would that not be the most reliable setup, keeping all the positives about GV and getting rid of the negatives?

Thanks,
JP

 

[wardmundy]

Question: Has there ever been a problem with GV incoming when setup the "old way" ie..( to forward to a SIPgate DID)?

Google broke "the old way" almost weekly for a very long time. This really is the first hiccup with Google using the new gtalk/jabber/jingle method. Of course, we've had a few missteps with Asterisk 1.8 but those seem to have been ironed out now. The major differences are the new method doesn't require two calls to complete an outbound call and you're not dependent on both Google AND another provider to get your calls to work in both directions.

 

[johnnypuffs]

@MichiganTelephone

Hi MichiganTelephone,

Am I dreaming here or did you not post a reply to my question below? Did you delete it? Did the mods delete it? If so, what was the reason? I didn't realize my question was off limits. If that is the case let me know so I don't mention it again..

Quick question.. I've wondered this for a while but never quite figured it out.. Is Google TRYING to break gvoice for people using asterisk or are these simply "upgrade" on their part that just happen to screw us all..

I read it and didn't have time to reply. Thanks for the answer.. I actually miscommunicated my message. I didn't mean to ask if Google was trying to break Gvoice for Asterisk users.. I meant is Google trying to break Gvoice for ANY PBX users of any system?

Are they trying to just keep people using the Gvoice interface and don't really want people using a PBX of ANY kind?

Your answer, if I remember correctly, would seem to imply that this is not the case, since users of some other systems (which I can't recall without seeing the reply) have not had these issues..

Thanks,
JP

 

[johnnypuffs]

Google broke "the old way" almost weekly for a very long time. This really is the first hiccup with Google using the new gtalk/jabber/jingle method. Of course, we've had a few missteps with Asterisk 1.8 but those seem to have been ironed out now. The major differences are the new method doesn't require two calls to complete an outbound call and you're not dependent on both Google AND another provider to get your calls to work in both directions.

Thanks for the reply Ward!

When you say "Google broke "the old way" almost weekly for a very long time" are you referring to incoming or outgoing?? or both..

My only concern is for the incoming!

When my customers can't reach me, that is a major problem. If GV outgoing dies it doesn't affect my life, I just use Vitelity or whatever..

Thanks,
JP

 

[reconwireless]

The Wait line before SendDTMF(1) is all you need unless you experience a DTMF issue in which case changing SendDTMF(1) to SendDTMF(11) seems to fix it. Thanks, ghurty, for the fix!!!

Yesterday I added the Wait(8) line and all worked well... Today GV was busted again I just made the SendDTMF(11) change and it is once again working.

 

[reconwireless]

Google broke "the old way" almost weekly for a very long time. This really is the first hiccup with Google using the new gtalk/jabber/jingle method. Of course, we've had a few missteps with Asterisk 1.8 but those seem to have been ironed out now. The major differences are the new method doesn't require two calls to complete an outbound call and you're not dependent on both Google AND another provider to get your calls to work in both directions.

I believe there are also some issues with getting multiple sipgate numbers if I remember correctly they only allowed one free one per mobile phone number it was paired with. Many users that I have seen have multiple GV numbers for different businesses or areas they want to get calls from. For example I have a business in NC and one in SC that I have separate numbers for. I assume that could be a reason that new Google DID's seem to be unavailable in many areas.

 

[MichiganTelephone]

Hi MichiganTelephone,

Am I dreaming here or did you not post a reply to my question below? Did you delete it? Did the mods delete it? If so, what was the reason? I didn't realize my question was off limits. If that is the case let me know so I don't mention it again..

I remember you asked the question and I recall replying but don't remember what I said. I may have noted that so far it seems that only Asterisk 1.8 users are experiencing this issue, and from what I've heard it is affecting neither FreeSWITCH nor Obihai device users (I recall saying that somewhere, but not sure if it was here). Other than that, I know I posted a reply but have no idea what I said. Of course, most days I'm lucky if I can remember what I had for dinner last night!

I will guarantee you that I didn't remove my reply, and I don't have the ability to remove your posts.

 

[wardmundy]

Seems to me there was a post that started off in another direction on another topic. The attempt to move it didn't go well. Sorry.

MORAL: Start new topics in new threads! If your sentence begins with "on a different subject," that's a big hint.

 

[twack1]

OK, so I was up 'till 5 AM and have now only had 1 cup of coffee, so forgive me if the $1,000,000 dollar questions has already been answered. I haven't found it so I'm asking right here:

"Is anyone else (other applications) that are using the gtalk/jingle interface with GV having the incoming problem that we are now experiencing?"

Now I'll go back to blankly staring at the forum screen and await an answer.

TIA

 

[twack1]

LOL! If only you had read the post two previous to your own you would have seen MT's ...



Time for a nap Twack1.

Lorne

MT's answer was kinda "iffy". I guess it wasn't strong enough to wake me up.

So.... We have a bug on our side -v- Google side? Or another way to put it, the PIAF implementation was sensitive to something that the others are not.

<having more coffee for lunch>