News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

GoogleVoice OAUTH + Configure locally

Started by azrobert, September 23, 2014, 04:55:08 PM

Previous topic - Next topic

Rick

I think I'll let the vendors argue who is at fault, but Steve you're getting the perspective from one side and the other side doesn't necessarily agree, and in fact are pointing fingers.

Callcentric has been in touch, by phone, with me today.  They are working with one of the two carriers with the issues (they didn't say which one) and they said the issue existed yesterday but did not exist today.  I then tested it and found it still does exist today and relayed that info to them minutes ago.

They explained, that from their perspective (perhaps a biased perspective), GV does not keep the routing consistent, so when an issue is "fixed" then some time later they see it's costing more money so someone may "unfix" it.  I'm not an engineer, nor do I play one on TV, so I don't know if that's one of the transit carriers sending calls a different way to CC, or GV using a different transit carrier.  Suffice it to say that CC seems to believe that GV is using the least expensive routing they can find, whether that's with a big player or not.  Again, that's what I'm being told - it may be biased, it may be wrong, it may be right.

I think the key is that the problem currently exists and this makes GV unreliable to use with CC TODAY.  While I've remedied the problem on my primary line by routing via IPComms and iNum, I don't see staying with that for long term as it begs "complex, please break me". 

Right now I'm watching and seeing if it gets fixed in the next few days.

I also volunteer to come to Hawaii and help Roger work through this difficult issue.  PM me and I will give you the info for you to book my travel.   :D

ramjet73

Quote from: Rick on October 16, 2014, 08:39:36 AM
I also volunteer to come to Hawaii and help Roger work through this difficult issue.  PM me and I will give you the info for you to book my travel.   :D
What issue? Getting fewer calls means more beach time. ;)

Seriously though, I'm still thinking about trying one of those "Cheap DID's". Unless Google chooses their initial transit carrier based on the forwarding phone number, that would certainly help to isolate the source of the CID and call completion problems.

ramjet73

SteveInWA

Quote from: Rick on October 16, 2014, 08:39:36 AM
I think I'll let the vendors argue who is at fault, but Steve you're getting the perspective from one side and the other side doesn't necessarily agree, and in fact are pointing fingers.

Callcentric has been in touch, by phone, with me today.  They are working with one of the two carriers with the issues (they didn't say which one) and they said the issue existed yesterday but did not exist today.  I then tested it and found it still does exist today and relayed that info to them minutes ago.

They explained, that from their perspective (perhaps a biased perspective), GV does not keep the routing consistent, so when an issue is "fixed" then some time later they see it's costing more money so someone may "unfix" it.  I'm not an engineer, nor do I play one on TV, so I don't know if that's one of the transit carriers sending calls a different way to CC, or GV using a different transit carrier.  Suffice it to say that CC seems to believe that GV is using the least expensive routing they can find, whether that's with a big player or not.  Again, that's what I'm being told - it may be biased, it may be wrong, it may be right.

I think the key is that the problem currently exists and this makes GV unreliable to use with CC TODAY.  While I've remedied the problem on my primary line by routing via IPComms and iNum, I don't see staying with that for long term as it begs "complex, please break me". 

Right now I'm watching and seeing if it gets fixed in the next few days.

I also volunteer to come to Hawaii and help Roger work through this difficult issue.  PM me and I will give you the info for you to book my travel.   :D

I've really tried to be patient, helpful, friendly, and all that other Boy Scout stuff with you.  In return, I've gotten a lot of complaining and cranky replies.

As you know, I am also a long-time, loyal Callcentric customer, and I am very familiar with their history on this issue.  I've been sympathetic to their position, and I did a lot of legwork to facilitate them actually troubleshooting the issue with the carriers that connect to them.

I already told you that Google uses several transit carriers, and that those carriers are some of the largest carriers in the industry, not Uncle Bob's Discount Phone Call and Stormdoor Company.  Callcentric apparently didn't bother to contact the other carrier I listed in my note, so, of course, they're not going to find the problem.  They're being unreasonable in claiming that it's all being caused by Google picking the lowest cost route.  That's frankly bullshit.  Yes, Google has routing algorithms.  All carriers do.  But, I can tell you from direct discussions with Google employees, that their focus is on reliability and call quality, not just cost.  They have monitoring and automation in place to specifically detect and solve those issues, which they do not want their users to put up with.  When a particular call route or particular carrier is causing problems, they either get it fixed, or ban that carrier on that route.  These issues are downstream from Google, and CC will either need to cooperate and troubleshoot, or GV users will simply stop using CC Telengy DIDs.  Perhaps CC doesn't make enough money on those DIDs to feel it's worth it to expend any effort on them.

My last word to you on this issue is to simply move on.  Either use Google Voice directly on your OBi and forget about CNAM, or pay the small amount of mony to get better reliability by using Callcentric with a non-Telengy DID like Roger suggested, or abandon GV and use CC or some other quality ITSP like voip.ms directly, without GV.   As always with telephony, the more direct and simple the path, the more reliable the service will be.

Rick

Steve - please re-read what I posted.  I stated what CC told me, I pushed back on them and told them exactly what the problem was, I told them that my VZW cell rings very quickly, so the issue is GV to CC, not GV to everything.  I told them that both carriers have logs of the issue, and I then dialed it numerous times to show them it still existed. 

You need to take a chill pill.  I'm not being cranky or complaining to you.  I merely posted what CC told me, and said it was probably biased and possibly wrong.  You read way to much into things. 

I have no intention of moving on.  I intend to push CC to resolve the issue.  I did that by opening a ticket and telling them that there FAQ was inadequate, and asked them to get more involved in solving the problem.  I also told that that if it would help, I suspected that the person who got my info to GV (you) MIGHT be willing to connect them directly to the GV engineer and the two carriers so that the same people are talking together and brainstorming how to resolve the issue. 

I don't know how a problem like this can exist for a month and it not be resolved by any of the parties, other than either they don't know it's happening, they don't know the magnitude that it's happening, or it's such a small portion of total volume that they cannot see it.  To me, it's unacceptable (forget who is at fault).  Doesn't matter if it's free service, the quality is unacceptable with these issues.  All companies involved (GV, CC, the two carriers, etc.) should be focused on fixing the problem and not pointing fingers.

If you want to keep helping, that's much appreciated (right now I don't need any help).  If not, fine, move on.  I appreciate the help you've provided.

I'm going to keep pushing CC.  I have no way to communicate to GV besides you, so if they ask for a contact I'll post that and you can provide it, or not, your choice.


Rick

Steve -

Here is Callcentric's latest reply to my trouble ticket (I added bold and color):

We cannot know for sure where the problem lies. As a provider our main concern here is whether your number can be reached from the PSTN. As you said before it can. You have introduced GoogleVoice into the equation which is the point of pain for this issue.

If GoogleVoice can provide the logs showing that the call is failing at our gateway then we can better investigate it. However our tests show that Bandwidth and Broadvox are able to properly complete to our number, including your as you experienced yesterday.

Can GoogleVoice provide you with information they received from bandwidth or Broadvox showing that the calls are failing at our switch? This would be helpful if it can identify the reason for the failure.


If you want to connect these guys, feel free to reference my trouble ticket #212848-11 and open a trouble ticket at CC and provide them with whatever info you can, or your Google contact's information.  I'm sure they would appreciate it, I know I would.

FYI, I responded to them as follows:

I'm a bit confused.  I demonstrated yesterday, and found the same result today, that calls placed to my GV number that forwards directly to Callcentric are NOT completing in a timely manner - which is exactly the same problem that has existed for a month.

So, I don't understand how you were able to successfully test my number completing with Broadvox and Bandwidth.com, since it does not work properly.  You dial my GV number and it takes 15 - 20 seconds to ring my phone (GV to CC), if I'm lucky I get one ring before GV picks up, sometimes a partial ring or no rings.  Forwarding my other GV number to IPComms then CC rings immediately.  Forwarding to my cell rings in about 5 seconds.

This problem has existed for at least a month, and nothing has changed in the past few days - so again, I don't know what you tested that worked successfully yesterday with my number.  It worked fine from May until about a month ago (can't pinpoint exactly when it started because I don't get enough call traffic to notice it, and I was ringing both my cell and house phones simultaneously).  

I have no way to get GV to contact you.  There is a contact that I know that has a contact at GV.  I am giving him your message in its entirety, and my response.  Since he is a CC customer also, I suggested he provide whatever info he can in a trouble ticket and reference my trouble ticket number so you can connect the dots.

I'm frustrated because GV has had discussions directly with Broadvox and Bandwidth.com about this issue.  You've had direct discussions with Broadvox and Bandwidth.com about this issue.  Perhaps ALL OF YOU could get on the phone together, making sure everyone is communicating clearly, and get this resolved quickly.

I am sending this to Steve also, my contact that knows GV engineers.  And, I will keep my fingers crossed that the four parties (CC, Broadvox, Bandwidth.com, and GV work TOGETHER, without pointing fingers, to resolve the issue and ensure that the you and GV are talking to the SAME contacts at Broadvox and Bandwidth.com.

Thank you.


Steve, if you could get them in direct touch with GV I, and I'm sure others, would greatly appreciate it.  

Rick

ramjet73

Quote from: Rick on October 17, 2014, 12:31:40 PM
Steve, if you could get them in direct touch with GV I, and I'm sure others, would greatly appreciate it.  
FYI, I purchased a California (closest I could get to Hawaii) Dirt Cheap DID a few days ago and haven't had a missed call or incorrect CID on my incoming Callcentric connection to my OBI202 via GV since then. I'll report back in this thread if I do in the future.

You can only expect so much for free and there are diminishing returns on spending more time on a problem that might be fixed temporarily and then come back again. My personal preference is to use a solution that I can trust to work even if it costs a few dollars a month. After all, how much do you spend monthly for your cell phone(s)?

ramjet73

Rick

I've asked CC to provide me with DIDs (not the free ones) to prove to them that the issue is with their free DIDs, and the problem is not GV, it's theirs.  There is absolutely no reason for this to exist, then be fixed, then exist, ...  Simple coding of the pathways to not use what breaks.

I have put my main number to forward to IPComms and then CC and it works flawlessly.  My other number gets infrequent calls and if I miss one the GV email will let me know within minutes, plus the cell can pick it up.

I had no issues from May until September.

MikeHObi

Quote from: Rick on October 18, 2014, 02:19:52 PM

I had no issues from May until September.

Such random issues with GV forwarding to providers is why I had to dump GV.  I can see what Callcentric is saying in that they want someone to show them that the call is failing on their equipment.  Because if you call the Callcentric DID from anything other forwarded through GV, the call completes.  Google seems to be trying to say that once they touch the first system outside of their network, the problem is no longer theirs.  So they are not actually trying to find where the problem is.  And since you can't actually get in touch with anyone for Support at google voice, you are just stuck.

A great free service when it works but sometimes it does't work. 
Obi202 user & Obi100 using Anveo and Callcentric.

Rick

With Steve's help we're very close to Google and CC engineers speaking on the phone.  They will then have the ability to prove the issue(s) - is it just free DIDs?  Or just DIDs handled by Telengy?  Is it just Broadvox or Bandwidth.com or both? 

If it's identifiable and fixable, then GV should be able to lock the problem pathways out of their algorithms and not have it occur again, if they want to. 

MikeHObi

Quote from: Rick on October 21, 2014, 12:04:35 PM
With Steve's help we're very close to Google and CC engineers speaking on the phone.  They will then have the ability to prove the issue(s) - is it just free DIDs?  Or just DIDs handled by Telengy?  Is it just Broadvox or Bandwidth.com or both? 

If it's identifiable and fixable, then GV should be able to lock the problem pathways out of their algorithms and not have it occur again, if they want to. 


That will be great for you and your DID.  But when I used GV I saw the same problem on my Callcentric DID and my Anveo DID.  That tells em that there needs to be a processes to expedite the corrections of these types of issues.  Would you consider the process you've gone through one that is expeditious?
Obi202 user & Obi100 using Anveo and Callcentric.

Rick

Quote from: MikeHObi on October 21, 2014, 12:15:07 PM
Would you consider the process you've gone through one that is expeditious?

Sorry, I Googled "expeditious" and got a 404 PAGE NOT FOUND....

Not even close.  One of the reasons I don't move my email to GMail or use GooglePlus and things like that is because of the lack of direct support. 

I like GV because I can easily decide what phones are forwarded to and get an email of every voicemail which even with poor transcription can also be clicked on and listened to.

I may be looking for a pay service that provides that level of capability soon...

rolandh

You might consider RingTo at www.ring.to. For what it is worth RingTo is an approved OBi service provider for devices purchased after May 15, 2014. That said RingTo got it's start as a call forwarding service with voicemail and messaging services similar to Google Voice. RingTo is a currently free service of Bandwidth.com. I use RingTo to forward to Callcentric's free Telengy DIDs without issue. You do need to port a number into them to use the service unless GrooVe IP on Android is an option for you.

dhobi

When I import a saved config from my OBI200 into the portal OBI Expert, it seems that I have to go through all the config pages and look for settings with a ! next to them and uncheck the OBITalk Settings checkbox next to the item. Is that right?
I'm trying to do steps 5-8 in the OP where I start with an existing configuration, in order to just fix GV on SP1 (I foolishly upgraded from 4350 to 4477 which now requires the portal to config GV and there's no firmware downgrade).

SteveInWA

Quote from: dhobi on November 07, 2014, 02:39:44 PM
When I import a saved config from my OBI200 into the portal OBI Expert, it seems that I have to go through all the config pages and look for settings with a ! next to them and uncheck the OBITalk Settings checkbox next to the item. Is that right?
I'm trying to do steps 5-8 in the OP where I start with an existing configuration, in order to just fix GV on SP1 (I foolishly upgraded from 4350 to 4477 which now requires the portal to config GV and there's no firmware downgrade).

Jeeeeeez.  Robert already documented how to do the backup/restore, which we discussed in your other thread.  Just do it.  Beeee Effffff Deeeeeeee.




dhobi

Quote from: SteveInWA on November 07, 2014, 03:13:44 PM
Quote from: dhobi on November 07, 2014, 02:39:44 PM
When I import a saved config from my OBI200 into the portal OBI Expert, it seems that I have to go through all the config pages and look for settings with a ! next to them and uncheck the OBITalk Settings checkbox next to the item. Is that right?
I'm trying to do steps 5-8 in the OP where I start with an existing configuration, in order to just fix GV on SP1 (I foolishly upgraded from 4350 to 4477 which now requires the portal to config GV and there's no firmware downgrade).

Jeeeeeez.  Robert already documented how to do the backup/restore, which we discussed in your other thread.  Just do it.  Beeee Effffff Deeeeeeee.

I'm not sure why you need to be so aggressive, I do not appreciate it.

I followed the instructions that said:
Quote
If you have a configured OBi, start at step 5.

And I have a question. If you cannot answer it, that's fine, please let someone else help because you are not helping. Thank you.

Taoman

Quote from: dhobi on November 07, 2014, 02:39:44 PM
When I import a saved config from my OBI200 into the portal OBI Expert, it seems that I have to go through all the config pages and look for settings with a ! next to them and uncheck the OBITalk Settings checkbox next to the item. Is that right?

Correct.

Quote from: dhobi
(I foolishly upgraded from 4350 to 4477 which now requires the portal to config GV and there's no firmware downgrade).

I guess it is debatable whether updating to the latest firmware version is acting "foolishly." Using the old firmware version also uses an old authentication method which Google has since deprecated. Google has only committed to supporting old authentication methods until 4-20-15. After that, who knows?
https://developers.google.com/accounts/terms

SteveInWA

Quote from: Taoman on November 07, 2014, 03:53:41 PM
I guess it is debatable whether updating to the latest firmware version is acting "foolishly." Using the old firmware version also uses an old authentication method which Google has since deprecated. Google has only committed to supporting old authentication methods until 4-20-15. After that, who knows?
https://developers.google.com/accounts/terms



Taoman, thanks for posting the authoritative link.  There should be no doubt that this is the official position of Google on this topic.

Rick

I hate to resurrect an old thread, but it's relevant, so I am.   :D

Summary:

Had GV until May 2014, then switched to GV forwarding to Callcentric.  Ran into issues last Fall where GV would not forward to CC in a timely manner, or at all.  Tried paid DID at Callcentric with no different result.  Tried getting Callcentric and Google Voice technical departments to talk and resolve the situation to no avail.  Convinced it was, and is, a GV issue.

Received a recommend to obtain an Inum number, which I did via Callcentric.  Then went to IPComms, got a free DID and forwarded it directly via INum.  So GV => IPComms =>Callcentric which rings OBi.  I predicted in this thread that this was not a long term solution.

Last Friday Inum stopped working.  Research via Callcentric, IPComms, and Googling showed Inum was "not accepting the invites" per IPComms, who supplied data showing this.  Attempting to contact INum, and the parent organization Voxbone, to no avail.  INum appears to be someone's hobby that left Voxbone, or Voxbone inherited it and doesn't really want it.  They apparently went to the Google School of Customer Non-SupportDSL Reports thread about Inum  

So today I went through the laborious and somewhat risky (bricking) task of updating my OBi's firmware to use GV the new way.  I let OBiTalk try to do it, but it always updated to the prior version, so I did it manually.  I then let OBiTalk provision both GV on SP1 and Callcentric on SP2.  Took multiple tries for each, even after resetting the OBi110 to factory defaults.  All in all a multi-hour process.  I then went in to the OBi directly via IP and disabled Auto Firmware Update, ITSP Provisioning, and ObiTalk Provisioning so nothing can be changed without my knowledge.

One of the problems I ran into was that I had removed Google Chat from Google Voice, and had to put it back - but couldn't because I use Chrome 64 bit and the Google Voice Plug In doesn't work with it (imagine that, a non-compatibility with Google products, I never would have imagined that).  It turned out to be easiest to do this on another PC versus trying to remove Chrome 64 bit and put Chrome 32 bit back. 

I'm at the point that if I run into any glitches I'm going to port my GV numbers out to Callcentric and be done with this.  We don't get many phone calls, I do make a lot but using the cell is perfectly fine and I can even make GV calls on it and not use my minutes.  I suspect that in the next few months GV will again hiccup and I'll move on.

I posted this so that anyone else relying on Inum forwarding knows of issues. 

I plan on launching Rick's Dixie Cup and String phone service, it would work better than many of the providers out there.

Throughout all of this Callcentric's support has been very helpful. 

restamp

Quote from: azrobert on September 23, 2014, 04:55:08 PM
The below procedure will allow us to continue to locally configure the OBi.

Starting with an un-configured OBi:
1. Add the device to OBiTalk.
Auto Firmware Update and OBiTalk Provisioning will be automatically enabled. The latest firmware will be downloaded to the OBi.
2. Define a GV trunk using OBiTalk.
3. Sign into the OBi locally and disable Auto Firmware Update and OBiTalk Provisioning.
4. Configure the OBi locally including changes to the GV trunk. The only settings you can't change are the GV UserID and PW.

If you need to add another GV trunk in the future:
5. Create a Configuration Backup locally in System Management/Device Update.
Check Use OBi Version.
6. In OBiTalk Expert import the backup. Now the OBi and OBiTalk will be in sync.
7. Locally enable OBiTalk Provisioning.
8. In OBiTalk define the GV trunk.
9. Locally disable OBiTalk Provisioning again.
10. Locally make any necessary config changes.

The config backup does not contain any passwords, so when you do the import there aren't any passwords on OBiTalk. When OBiTalk downloads the new config after you define the GV trunk it does NOT overlay the locally defined passwords with blanks.

If you have a configured OBi, start at step 5.

This procedure is acceptable for me. How often do we change GV passwords or add a new GV trunk? However, I still hope OBihai adds OAUTH 2.0 to the local interface.
This reply is to azrobert's initial post, not the discussion it morphed into.

This afternoon, I needed to add a GV connection to one of my OBi's.  I can attest that Robert's instructions work, but there are a couple gotchas:

+ Perhaps the most serious problem, after completing this exercise, I found that all my Speed Dials were missing.  The OBiTalk website maintains one list of Speed Dials in common with all the devices assigned to one account, whereas I keep separate lists per device.  (FWIW, I was able to drop a copy of the new .xml file, cut and paste the original entries into it, and then successfully re-import it.  Thank heavens it does not come with a checksum.)

+ There is one password OBiTalk maintains, and that is the admin password.  Furthermore, OBiTalk replaced the device's password with the one it knows.  Not hard to change back after the fact, but something one should be aware of.

+ Diffing the before and after .xml files revealed that several parameters had been altered.  I can only guess that OBi engineers at some point decided that the defaults weren't optimal.

+ Also serious (and I'm not sure I understand why it happened in the first place), but after I had locked out OBiTalk the first time, I had converted SP1 from CHAT to SIP (actually Simonics).  The OBiTalk database retained the original configuration, even after I pushed the latest .xml backup up to it to sync it.  It then reconfigured SP1 to its original CHAT incarnation, wiping out the changes I had made for Simonics.  Again not difficult to fix, but something one should be aware of up front.

And an interesting discovery: I made a mistake while fixing the above problem by accidentally leaving the ITSP SignalingProtocol field set to "Google Voice".  Even though everything else was otherwise configured for Simonics, it none-the-less connected successfully to GV using CHAT.  I flipped this field back and forth from GV to SIP several times to verify it was the only field that needed to be changed to convert from a CHAT connection to a SIP one or vice versa.  Apparently when changing from CHAT to SIP, the OBi leaves the OATH2.0 credentials in place so that they do not have to be reloaded if one later selects "Google Voice" once again -- something to keep in the back of your head.  (I did not test whether the OATH2.0 credentials are linked to a particular trunk or whether one can move a GV instantiation from one SPx to another without revisiting OBiTALK, but my guess is you cannot.)