Google Voice is now Officially Supported on OBi VoIP devices
McKayCR:
Question... I have Obi100 with GV, I never stopped using it. I noticed that I still can send and receive phone calls even after it was supposed to not work. Now the officially supported message comes out with a tutorial on how to use it. This tutorial talks about creating an account with Obihai and managing your device through their portal.
Is this truly necessary under the new "officially supported" continuation of service? I'm thinking the answer is no since my system seems to still be up based on my original configs.
My assumption is that the portal is just an aide for the less tech savvy folks, and that it is not really required. Just looking for confirmation on that.
By the way, I had Ooma before I found Obi100, and Ooma is by far less superior in service and quality. I'm hooked on Obihai.
SteveInWA:
Quote from: ramjet73 on September 11, 2014, 09:59:21 pm
Quote from: SteveInWA on September 11, 2014, 09:31:07 pm
If you care about or need CNAM, I suggest using a Callcentric DID number as your GV forwarding destination. It isn't perfect, and they send a lot of not-so-helpful "Los Angeles, CA" results for example, but it does work.
If found this FAQ about CNAM on the Callcentric website and apparently they only officially support the inbound look-up for their paid services. I mention that because I know that many Callcentric users take advantage of the free DID with free inbound calls service.
That's interesting, because I have two paid CC DIDs and a free NY State DID. Until the past couple of weeks ago the free DID, which is my GV forwarding number, was passing CNAM just fine. It has occasionally been sending "UNKNOWN" recently, but I haven't taken the time to do a definitive test. I just now called it directly (not through GV) and it did send CNAM. Perhaps they changed their policy recently (and maybe just "grandfathered in" my old number). As Archie Bunker used to say, I am not going to "slug a gift horse in the mouth."
Limiting it to their paid DIDs seems reasonable to me (as you pointed out, there's a cost to providing CNAM). In any case, a paid CC DID is so cheap, if CNAM is important to the user, then it's a good option.
SteveInWA:
Quote from: McKayCR on September 11, 2014, 10:11:27 pm
Question... I have Obi100 with GV, I never stopped using it. I noticed that I still can send and receive phone calls even after it was supposed to not work. Now the officially supported message comes out with a tutorial on how to use it. This tutorial talks about creating an account with Obihai and managing your device through their portal.
Is this truly necessary under the new "officially supported" continuation of service? I'm thinking the answer is no since my system seems to still be up based on my original configs.
My assumption is that the portal is just an aide for the less tech savvy folks, and that it is not really required. Just looking for confirmation on that.
By the way, I had Ooma before I found Obi100, and Ooma is by far less superior in service and quality. I'm hooked on Obihai.
Yes, you need to do the GV configuration via the portal. The portal is involved in the Google OAUTH secure token exchange process. There are some threads from a couple weeks ago about how to back up and restore your device's local configuration if you wish to continue using the local web browser GUI for other tasks.
ramjet73:
Quote from: SteveInWA on September 11, 2014, 10:17:01 pm
That's interesting, because I have two paid CC DIDs and a free NY State DID. Until the past couple of weeks ago the free DID, which is my GV forwarding number, was passing CNAM just fine. It has occasionally been sending "UNKNOWN" recently, but I haven't taken the time to do a definitive test. I just now called it directly (not through GV) and it did send CNAM. Perhaps they changed their policy recently (and maybe just "grandfathered in" my old number). As Archie Bunker used to say, I am not going to "slug a gift horse in the mouth."
I'm not sure when "UNKNOWN" is displayed but here is the explanation I got from a Callcentric tech about why I am getting "Private caller" (asterisks represent numbers masked for security reasons):
Quote
To further clarify the initial questions, Telecom Providers use multiple Underlying Carriers to complete the calls. These Underlying Carriers are the direct Interconnects. Although Google isn't exactly a true Telecom Provider, they use Underlying Carriers to complete the calls as well.
The Underlying Carriers provide routes at different rates. We suspect that one of Google Voice's Underlying Carrier is using a cheaper route to complete calls to the Telengy Network(Phone Number Provider for 1631*******). We say this because some Underlying carriers do modify or strip the Caller ID.
We see that the last call that came in was Anonymous. Here is a snippet from the Call INVITE Packet for that particular call:
To: 1631*******<sip:1631*******@xx.xx.xx.xx>
From: <sip:1949*******@xx.xx.xx.xx>;tag=361*******-34294
Remote-Party-Id: <sip:9493********@xx.xx.xx.xx;user=phone>;party=calling;id-type=subscriber;privacy=uri;screen=yes
Please observe the "Privacy=uri" portion. This indicates that the call is being sent to us as ANONYMOUS and we should not pass the caller ID information for the call. As per the SIP RFC our servers are then stripping the CID information(1949xxxxxxx) when sending it to your device. This is beyond our control, Google needs to change or remove the privacy flag in order for the call to be forwarded with caller ID information.
A number of customers have tried to contact Google Voice however there has been no response from their end. You may try contacting them and if they do respond we will be happy to submit our trace logs and join the troubleshooting process.
If you have any further questions please feel free to contact us. Thank you
I'd love to get Google involved with this issue but don't know where to start.
Do you have any suggestions?
SteveInWA:
ramjet:
Yes, I looked into this with Google last year sometime, when it was rampant. At that time, there was some finger-pointing back and forth between Google and CC about it. I eventually got Google to deal with the issue, as described by the CC tech's note. It seems to have reappeared, although not as frequently. It's intermittent because like the CC tech said, the calls can pass through different intermediate or "transit" carriers, depending on cost algorithms. I now have a direct contact at Google who may be willing to fix it if you would like to help.
If so, I ask that you wait a couple of weeks, because there is a lot of high-priority work going on there now, with the Hangouts updates. Then, on a weekday morning, submit a post on the GV Help Forum. You can mention my forum nickname (For Bluescat:) in the title so I'll see it. We'll need at least 3-5 sample inbound calls placed to your GV number, which forward to your CC free (Telengy) DID number, and delivered missing or bogus CNAM. We'll need the date and times of the calls, the last 4 digits of your GV number, the last 4 digits of your CC DID, and the last 4 digits of the caller's number and if possible, their carrier (their telephone company). We need this data to be "fresh", i.e., that you collect the samples and post them immediately, on a weekday, because phone switch logs can get purged every 24 hours, making it impossible to troubleshoot.
If you can do that, the Google engineer can look at the transit carriers that were used for those calls, and fix the issue.
Navigation
[0] Message Index
[#] Next page
[*] Previous page