GoogleVoice OAUTH + Configure locally
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-Support. DSL 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.)
Navigation
[0] Message Index
[*] Previous page