There has been much whining on this forum by users that configure their OBi's locally (including myself) about the new GV OAUTH authentication forcing us to use OBiTalk to configure our OBi devices.
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.
+1 Thanks
Quote from: azrobert on September 23, 2014, 04:55:08 PM
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.
Thanks for trying this out.
I wasn't too keen on messing with my "production" setup. So kudos for letting us know how it worked out.
Seems simple enough, except for:
Define a GV trunk using OBiTalk.
I only use the local configuration options, and have Callcentric on both SP1 and SP2. I have two GV numbers, each of which forwards to a Callcentric number, and then rings the OBi. For about a month, GV has not forwarded calls reliably - GV says it's a CC issue, CC says it's a GV issue. I have little hope it's going to get resolved.
So unless I want to move from GV (which I may), it appears I have to do something like this.
Does this mean that I can keep CC on SP1 and SP2, because the trunk is setup for GV? I really don't understand the trunk concept. Reading OBi's documentation doesn't help. :o
"Trunk" is telco jargon, meaning a circuit or, in this case, a ITSP registration, providing a connection from your premises to some telephone company or ITSP.
Substitute the term "service provider configuration" in the context of OBi-speak, and it makes more sense.
You currently have Google Voice set up to forward to Callcentric numbers. That setup is on the Google Voice website, not on your OBi, which has the CC numbers configured. So, you can decide what you want to do with GV, and either enable "Do Not Disturb" on GV settings, or delete your GV number(s) entirely. I'd suggest just placing them into DND and recording a new voicemail greeting directing people to call your CC number(s), for now, until you are darn sure you want to get rid of GV. It's difficult to get a new GV number at the moment, due to dwindling supply.
Since you already have Callcentric defined on SP1 and SP2, if you now decide to use those numbers directly, without using GV, then you don't have to do anything at all on your OBi. IF you also have GV defined on one of your SP slots, then just delete it locally.
TL;DR: in your particular case, since you are not adding GV service, you don't need to use the OBiTALK portal now.
Quote from: Rick on October 14, 2014, 12:18:48 PM
I really don't understand the trunk concept.
You already have 2 Callcentric "trunks" configured on your OBi. I think you are misunderstanding the use of the word "trunk" in the context that azrobert is using it. He is not referring to configuring a "Trunk Group" if that is what you are thinking of. A "trunk" is just a DID in this context.
Suggestion: get yourself an IPComms free DID (2 if possible) and forward those DIDs to your Callcentric account(s) via iNum. (Order a free iNum number(s) from CC if you don't already have one). Add the DID(s) as forwarding numbers in your GV accounts. If forwarding to your CC DIDs is really that unreliable then uncheck the boxes in front of those DIDs.
Although you won't get free CNAM the call will be forwarded reliably as will the number. If you don't use the CC phone book I would highly recommend it as it supports CNAM override. So if most of your incoming calls are already entered into your CC phone book it will mitigate, to some degree, not having CNAM on your IPComms DID(s).
Thanks for the translation(s). Yes, I understand SP instead of Trunk I was confusing it with Trunk Groups.
Steve - Thanks for the idea, but I really want the GV number (which is our old home TELCO number) to ring the house phones, not give a recording.
Taoman - I get the concept, but don't understand how iNum is used to forward IPComms' DID to Callcentric. Interesting, when I try to go to IPComms website I get Fatal error: Cannot call overloaded function for non-hobject in /home/content.... A provider whose website doesn't work? They seem to talk about it on their Facebook page back in September.
I don't care about CNAM. We get a handful of calls a week. What I more care about is that when people call the phone ring - which hasn't been happening for weeks now due to the GV==>CC problem.
Quote from: Rick on October 14, 2014, 01:28:14 PM
Taoman - I get the concept, but don't understand how iNum is used to forward IPComms' DID to Callcentric. Interesting, when I try to go to IPComms website I get Fatal error: Cannot call overloaded function for non-hobject in /home/content.... A provider whose website doesn't work? They seem to talk about it on their Facebook page back in September.
I don't care about CNAM. We get a handful of calls a week. What I more care about is that when people call the phone ring - which hasn't been happening for weeks now due to the GV==>CC problem.
I just got to their web site without issue but use this url:
http://ipcomms.net/freedid (http://ipcomms.net/freedid)
Don't try using Facebook. Just call the number listed.
You should be able to forward IPComms DIDs to Callcentric via standard SIP URI. However, because of an "incompatibility" between the back end DNS servers of IPComms and CC that isn't possible so you have to use iNum (which is really SIP URI via a different route). You would just configure the IPComms DID on their web portal to forward to your CC iNum number. I've been doing this for quite awhile and it is very reliable.
That URL yields:
Fatal error: Cannot call overloaded function for non-object in /home/content/37/11662737/html/ipcomms/libraries/gantry/gantry.php on line 432
both in Google Chrome and IE.
Quote from: Rick on October 14, 2014, 01:44:51 PM
That URL yields:
Fatal error: Cannot call overloaded function for non-object in /home/content/37/11662737/html/ipcomms/libraries/gantry/gantry.php on line 432
both in Google Chrome and IE.
Yikes! I use Firefox but I just now tried it in IE and Chrome and had no issue. What is your OS and what versions of browsers are you using?
Can you get here?
http://2way.ipcomms.net/ (http://2way.ipcomms.net/)
Called them, they fixed it on their end.
I should note that IPComms supports direct registration with SIP credentials. So you could remove iNum and Callcentric out of the equation entirely if desired. However, IPComms is more of a SIP trunking company so their web portal is minimalistic to say the least. But if you don't care about CNAM then you may wish to consider this option also. I prefer to forward to CC because of their feature rich web portal and their phone book which supports CNAM override. However, this would mean reconfiguring your OBi device.
Whoa. This may not work for you. I only have one free IPComms DID. I know Callcentric will give you two free DIDs but I just saw this on the IPComms web site regarding their free DID offering:
QuoteLimit of 1 FreeDID per user. Registration of multiple FreeDID accounts by a single user is not permitted, and will result in immediate service cancellation.
I called them, jury-rigged into their site (which is full of typos), read info, found the sign up form, they called, waiting for email.
Figure I can use this for main line which gets all the calls. I setup two inums on CC.
Quote from: Rick on October 14, 2014, 02:48:09 PM
I called them, jury-rigged into their site (which is full of typos), read info, found the sign up form, they called, waiting for email.
Figure I can use this for main line which gets all the calls. I setup two inums on CC.
Once you get your DID, login to your account at 2way.ipcomms.net and click on DID and forward your DID to your CC iNum number. Here is the exact syntax:
SIP/XXXXXXXXXXXXXXX@sip.inum.net where XXX.... is your iNum number.
There is nothing to do on the Callcentric side of things if you already have your iNum number. Also, you could keep your CC DIDs checked in your GV account. Won't hurt anything. First DID to hit your OBi wins. I keep both my CC DID and my IPComms DID checked in GV. The IPComms DID wins about 80% of the time.
If you're feeling adventurous you could set up a Voice Gateway with your IPComms SIP credentials. That way you could make outbound calls thru IPComms to use those 50 free minutes of outgoing they give you. However, you would need to use IP Authentication since you're not using registration. This means you would need a static IP address and you would need to contact support@ipcomms.net and have them enable this. They also allow you to spoof your outgoing CID.
First, thanks to Taoman for providing this information. I'm going to relate my experience so it may help others.
First - my setup. I have two GV phone numbers, one for home and one for business. The home number is my original TELCO number, we want to keep it. I ported it to GV when I initially setup my OBi several years ago.
Then I setup Callcentric for E911. After CC had issues with DoD attacks and then the Sandy power failures, I turned off E911 as it was unreliable.
In May, based on the upcoming deadline for GV working on the OBi, I reactivated my Callcentric account, and setup two numbers. Each GV number forwarded to a CC number, and I setup CC on my OBi. This gave me unique rings so I could tell if a call was personal or business (neither line gets a lot of activity).
In September, I started having issues with GV. My GV number is forwarded to my cell and to my CC number. My cell would ring, but not the OBi. I thought this was an OBi issue until I played around and determined it was an issue with GV communicating with CC. It got to the point that the house phone would not ring at all, so if someone called I HAD to have my cell setup as a forwarding phone and had to answer the call. Well, that's not reliable enough service for me. After a few missed important calls (luckily GV sends an email when a voicemail is left), I probed some more and sought the help of Steve.
I also had the problem that during a call the audio would become faint and scratchy on my end (we'll see if that is now resolved).
I provided Steve with my call logs, and he contacted his contacts at GV. They contacted their contacts at the companies that complete the calls for them. The result has been that GV says the issue is at CC. CC says the issue is at GV. In other words, "mine's bigger".
On CC's site, there is now an FAQ (with no date as to when posted) that says:
Are there any known issues with Callcentric and GoogleVoice?
At this time we have identified that GoogleVoice has trouble forwarding and placing calls to random Callcentric numbers. The symptoms include:
Lost calls
Dropped calls
Incorrect callerID
Anonymous callerID
We would like to make it clear that there is no difference in quality nor functionality between free numbers and paid numbers offered by Callcentric. Customers experiencing these GoogleVoice issues will note that they can reliably receive incoming calls directly on their Callcentric numbers when GoogleVoice is not involved.
Based on our industry experience and extensive testing/troubleshooting; we believe this issue may be due to the outgoing carrier being used by GoogleVoice potentially using poorer quality routes. We are currently working with GoogleVoice on this issue to try to attain additional information and also to see what changes can be made on their end (GoogleVoice) to resolve the problem satisfactorily.
Unfortunately, as it has been determined that the above mentioned concerns are related to the way that a third-party provider (GoogleVoice) provides service and delivers calls; we will not investigate your specific issue if it relates to any of the symptoms above.
With that said, we are committed to providing the best service experience possible for our customers and with this in mind we will continue working with GoogleVoice regarding these concerns. Further updates and information will be provided as soon as they are available. In the interim, you may contact Google to inform them of this issue and show that it affects a wider range of their subscribers.
I posted a trouble ticket to CC giving them the specific info Steve had given me. Their response was
We are currently investigating the issue further. Once we have more information, we will update this ticket. [/color]
In the meantime, I need reliable phone service. I need the phone to ring when someone calls. Taoman suggested IPcomms, a company I had never heard of (not that this means anything, I'm not a VoIP expert - I got an OBi to cut my phone bill to near nothing with GV).
My initial experience with them has been very disappointing. Their website was unreachable, I found certain pages accessible but not others. They made a change, and most, but not all of the pages were reachable. I found multiple typos on the site (a yellow flag to me). I filled out a form (they push you to like them on Facebook but I found the form without doing that), and then they called to ask a few questions and then said I would receive a setup email. That was at 5:13PM last night. I never got the email, sent a trouble ticket, got response to check my spam folder, went back and forth during the evening, was asked to give an alternate email address. This morning I discovered that after I went to bed I received an email, to the original email address at 10:50 PM. Since I only got 1 email (and none to the alternate email address), it's not due to delays in their system it's due to something not working until they fixed it.
During the evening I also setup iNum numbers as Taoman suggested on Callcentric's site. I was able to setup two, thinking I might be able to forward both GV numbers if I have to. Unfortunately, as was noted by Taoman, IPComms only gives you one free DID. So yes, I can handle all my calls by forwarding both GV numbers to IPComms, but I'll lose any distinct ring if I do that. Since I get infrequent calls, and since my cell is setup as forwarding (and doesn't use minutes), this is fine for now.
This morning I logged into IPComms and discovered that you cannot change your initial password (which was in the email) online, so I asked how to change it - don't want it sitting in email folders anywhere. I followed Taoman's instructions, but it took several tries to get IPComms system to show the info accurately, and I have no idea why. Their website as noted as numerous typos, no "Call Treatments" that I can see (which would allow me to take my business calls and send them to the second iNum number I setup), no way to change a password, etc.
Once setup I tested things. If I don't forward to IPComms, my house phone takes about 15 seconds to ring (vs. 6 for my cell to ring). That means that in 10 seconds or less GV is going to ask the caller to leave a Voicemail message). I then forwarded my GV number to IPComms and retried the call. My house phone rang instantly. My OBi is still setup for CC and I do not have to put GV on it and use the portal or update my firmware (and take the risk of possibly bricking the OBi).
So, as of now, I have "fixed" the problem. I've also proved that GV can forward immediately to IPComms (a California number), which unscientifically proves to me that the issue MAY be with CC.
If this keeps working then I have no reason to change anything. IPComms is free for incoming calls, CC is free for incoming calls, and GV is free. If GV and CC stop the "mine's bigger" contest and actually fix things, then I can remove IPComms from the loop if I want.
I also noted that none of the IPComms account pages are secure. Not one of them. Big concern.
I hope things keep working, my initial experience with IPComms screams "Danger Will Robinson, Danger". We'll see. As I said I hope to help others by posting this.
Callcenter's update to my trouble ticket a little after 12 noon:
We have opened a ticket with one of the problematic carriers to find out what could be causing the issue. We will get back to you once we have further information.
Apparently, by providing the info that Steve gave me (i.e. carrier names), that resulted in some movement.
If this doesn't work, I'll see if Steve can get the GV people to get their carrier's people to contact the right person at CC to get this working.
Then, if they all chip in and send me $20,000, we'll be good.
Quote from: Rick on October 15, 2014, 09:45:38 AM
"I provided Steve with my call logs, and he contacted his contacts at GV. They contacted their contacts at the companies that complete the calls for them. The result has been that GV says the issue is at CC. CC says the issue is at GV. In other words, "mine's bigger"."
That's not an entirely accurate description of what happened, as it implies that GV and CC are just blaming each other, which is not the case at this point in time. The point of failure is downstream from GV, and it's between the last carrier in the routes, and CC's switches. I worked with Rick to collect logs of his calls. I then worked with Google to compare those logs to his GV account's logs, and then to examine the routes that the failed calls took. Google identified the intermediate, or "transit" carriers that were used to send those calls to CC. GV then contacted those carriers to troubleshoot. Both of the carriers (which, contrary to CC's description, are major market players, not cheapo/low-quality) found that the calls were unable to route to CC for some reason).
I gave that information to Rick, and encouraged him to pass it to CC. It's good to see that CC is finally willing to contact the carrier(s), given that it won't get fixed without their participation.
Quote from: Rick on October 15, 2014, 05:14:25 AM
In the meantime, I need reliable phone service. I need the phone to ring when someone calls. Taoman suggested IPcomms, a company I had never heard of (not that this means anything, I'm not a VoIP expert - I got an OBi to cut my phone bill to near nothing with GV).
Have you considered purchasing a Dirt Cheap DID through Callcentric as was recommended by one of their technicians in response to my trouble ticket on a similar CID issue:
Quote
You can try purchasing a Dirt Cheap DID (http://www.callcentric.com/dids/phone_number_sale) which is provided by a different carrier. If you would like, you can purchase a Dirt Cheap DID and if the caller ID issue persists, we will provide you with a full refund for the product (as long as you update us within 48 hours of purchasing the number).
Contrary to their statement that customers with free DID's get the same service as those that pay, there is some evidence to the contrary, and the suggestion to buy a DID essentially to change the routing tends to contradict that.
I've been resisting that suggestion in principle since Callcentric does not have any option to acquire a Hawaii DID, paid or not, but am getting close to biting the bullet and spending $2.95 for a month just to satisfy my curiosity. If the quality of your phone service is important to you that's something you might want to consider as well.
Prior to testing again with Callcentric I had migrated my primary DID connection back to Google Voice but it doesn't offer all the features (like message waiting) of a real ITSP using SIP connections. If the caller ID issues with free Callcentric DID's don't get resolved soon I will probably use my voip.ms account instead where I can get up to 3500 incoming minutes (way more than I need) for a $1 setup fee and $6.95 per month, including a Hawaii (808) DID number. Or just live with the limitations of Google Voice which I will continue to use as my primary service for outbound calls regardless of how my inbound calls are handled.
ramjet73
Roger, given your location in Hawaii, and your preferences for phone service, I think voip.ms is the best solution. I'd write off the extra cost as the "I get to live in Hawaii surcharge"!
Quote from: SteveInWA on October 15, 2014, 07:01:21 PM
Roger, given your location in Hawaii, and your preferences for phone service, I think voip.ms is the best solution. I'd write off the extra cost as the "I get to live in Hawaii surcharge"!
8)
ramjet73
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
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
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.
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.
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
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
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.
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.
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.
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?
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...
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.
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).
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.
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.
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 (https://developers.google.com/accounts/terms)
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 (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.
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 (http://www.dslreports.com/forum/r29925220-iNum-down-)
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.
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.)