Will GoogleVoice stop working on all deployed OBi devices after May 15?

[lhm.]

Voip.ms allows spoofing CID to shock your friends, as in WH, NSA & CIA. Just do not pretend to be them in the call or they will come after you.

 

[giqcass]

I would not call it spoofing. You can set any registered number( which has to be verified) as your caller ID, it cannot be just any number. So I can pick any of my Localphone DID's, my 2 GV numbers , My Callcentric number or my 2 cell phone numbers. That's it.

Call it whatever you want.  Each provider calls it something different.  Spoofing is a generally accepted term. Despite having a negative connotation it accurately describes what localphone is doing.  When a service sends caller ID for a number of which it is not the authoritative register the service is spoofing the caller ID. So if localphone sends your Google Voice number it is spoofing it.

[sdb-]

It is not "spoofing" unless you are sending a caller id that does not reach back to you.

There is no direct tie or association between a CID which is an identifier for an incoming trunk, and an outgoing trunk.  That association has to be created by someone.  If you go to the phone company as a home or small business owner and rent a phone line, the phone company forms the association.  If your business grows and you need more incoming lines than outgoing (or the opposite) then the phone company no longer knows how you will be associating your lines, and so will have you designate the CID(s) to be used for your outgoing line(s).

Likewise a VOIP provider needs you to make that CID designation because they don't know how your lines are configured.  Therefore when you set your CID on an outgoing trunk it is not spoofing, but is merely creating the association which people expect to exist, but which does not naturally exist.

[telecomm]

A lot of people will be moving to localphone for outgoing calls.  They start at 1/2 cent per minute pay as you go or 1/10 of a cent per minute if you buy a bucket of minutes each month and they will "spoof" your caller ID so it appears the call came from your Google Voice account.  Any service with caller ID "spoofing" will work.

The old Asterisk method will work as well but when Google changes something it can break in which case you must wait for an update.  It has worked pretty well for a long time but you never know.

Thanks, I got a free DID from IPKall today.  I tested it and my results are not that good.  Sometimes the call comes through, other times it does not.  I have the free IPKall and the free Callcentric DIDs setup so my GV number rings them via my Callcentric SIP, but still they only work part of the time.  I have tested seperatly, without GV (direct DID), and still the same unreliability.  Good thing about GV is at least the VM will go on and ask the caller to leave a message for those calls that never ring for me.
I wonder if going through Callcentric direct would provide more reliability?  To pay for a plan to include incoming and outgoing calls on a non free DID line.
I have this setup for my wife with her business.  She does not seem to think she is losing calls and all go to GV voice mail, but I wonder.  Her internet is via ATT UVerse, if that even matters, and mine is WOW.  I will have to go to her office and test, and if I find the same thing, switch to a more reliable method and just pay the 20 bucks or so a month.  Of course, I welcome all ideas.

[SteveInWA]

Thanks, I got a free DID from IPKall today.  I tested it and my results are not that good.  Sometimes the call comes through, other times it does not.  I have the free IPKall and the free Callcentric DIDs setup so my GV number rings them via my Callcentric SIP, but still they only work part of the time.  I have tested seperatly, without GV (direct DID), and still the same unreliability.  Good thing about GV is at least the VM will go on and ask the caller to leave a message for those calls that never ring for me.
I wonder if going through Callcentric direct would provide more reliability?  To pay for a plan to include incoming and outgoing calls on a non free DID line.
I have this setup for my wife with her business.  She does not seem to think she is losing calls and all go to GV voice mail, but I wonder.  Her internet is via ATT UVerse, if that even matters, and mine is WOW.  I will have to go to her office and test, and if I find the same thing, switch to a more reliable method and just pay the 20 bucks or so a month.  Of course, I welcome all ideas.

As of today, I would not recommend using either IPKall or Callcentric's free DID numbers as Google Voice forwarding destinations.  Google's carrier is experiencing problems connecting to these numbers, resulting in various symptoms, including incorrect or missing caller ID data, delays in connecting, or failure to connect.  I've escalated this issue to Google, but I am not optimistic it will be fixed in the near term.  Some Anveo users are experiencing the same problem.  From what we've seen so far, Callcentric's paid DIDs, (in other words, DIDs you select in your area code of choice, and pay a monthly fee to maintain) work fine as forwarding targets for GV.  Speculation (and only speculation at this time) is that the cause is the least-cost routing being used by GV's CLEC (carrier) to connect to the CLECs providing the free DIDs.  Because this routing can be different from one call to the next, some users' free DIDs seem to work sometimes, and sometimes not, and some users' DIDs always or never work. 

My own opinion as of today is that it is a waste of time to experiment further with swapping free DIDs until the CLECs resolve the issues.

[giqcass]

I have not personally had any issues with an IpKall number.  My thought here is if you aren't having trouble then just leave everything alone.  I would also try to keep things as simple as possible.  For reliability I have been forwarding my IpKall number directly to my Obi.  I wish Google would allow us to forward directly to a sip address.  That would remove a lot of issues.  If you are willing to port your number Anveo and Callcentric provide most Google Voice call routing capabilities for a small price.  They even have a few extra services.  Localphone in my opinion remains an excellent choice for outbound calling but it offers no bells or whistles for inbound routing.  That is why I choose to use them as an outbound only service.

[telecomm]

Thanks, I got a free DID from IPKall today.  I tested it and my results are not that good.  Sometimes the call comes through, other times it does not.  I have the free IPKall and the free Callcentric DIDs setup so my GV number rings them via my Callcentric SIP, but still they only work part of the time.  I have tested seperatly, without GV (direct DID), and still the same unreliability.  Good thing about GV is at least the VM will go on and ask the caller to leave a message for those calls that never ring for me.
I wonder if going through Callcentric direct would provide more reliability?  To pay for a plan to include incoming and outgoing calls on a non free DID line.
I have this setup for my wife with her business.  She does not seem to think she is losing calls and all go to GV voice mail, but I wonder.  Her internet is via ATT UVerse, if that even matters, and mine is WOW.  I will have to go to her office and test, and if I find the same thing, switch to a more reliable method and just pay the 20 bucks or so a month.  Of course, I welcome all ideas.

As of today, I would not recommend using either IPKall or Callcentric's free DID numbers as Google Voice forwarding destinations.  Google's carrier is experiencing problems connecting to these numbers, resulting in various symptoms, including incorrect or missing caller ID data, delays in connecting, or failure to connect.  I've escalated this issue to Google, but I am not optimistic it will be fixed in the near term.  Some Anveo users are experiencing the same problem.  From what we've seen so far, Callcentric's paid DIDs, (in other words, DIDs you select in your area code of choice, and pay a monthly fee to maintain) work fine as forwarding targets for GV.  Speculation (and only speculation at this time) is that the cause is the least-cost routing being used by GV's CLEC (carrier) to connect to the CLECs providing the free DIDs.  Because this routing can be different from one call to the next, some users' free DIDs seem to work sometimes, and sometimes not, and some users' DIDs always or never work.  

My own opinion as of today is that it is a waste of time to experiment further with swapping free DIDs until the CLECs resolve the issues.

Thanks!  Any idea why paid DIDs might be working better?  I think I will try that just in case, at least for the office phone.

[telecomm]

I have not personally had any issues with an IpKall number.  My thought here is if you aren't having trouble then just leave everything alone.  I would also try to keep things as simple as possible.  For reliability I have been forwarding my IpKall number directly to my Obi.  I wish Google would allow us to forward directly to a sip address.  That would remove a lot of issues.  If you are willing to port your number Anveo and Callcentric provide most Google Voice call routing capabilities for a small price.  They even have a few extra services.  Localphone in my opinion remains an excellent choice for outbound calling but it offers no bells or whistles for inbound routing.  That is why I choose to use them as an outbound only service.

Thanks.  Would you mind pointing me in the right direction on how to direct forward the Ipkall # to the Obi?

[SteveInWA]

Thanks!  Any idea why paid DIDs might be working better?  I think I will try that just in case, at least for the office phone.

I believe it is because the problem may exist in the choice of call routing between Google's local exchange carrier (CLEC), and Callcentric's CLEC, http://www.telengy.net that owns the blocks of DIDs CC is issuing for free.  CC leases their paid DIDs from several other CLECs (depending on the location of the "rate center" or local calling exchange of the DID).  It's always possible that those DIDs will suffer the same fate at some point, but there haven't been any reports of problems so far on CC's paid DIDs.

I'm going to go off-topic here, to say that, on the Google Voice Forum, we regularly try to discourage people from using GV for business purposes.  There's no direct customer support from Google, and when things go wrong (like this, or worse, when your clients can't reach you), it can damage your business financially, and damage your reputation for responsiveness.  Decide if the small amount of money saved is worth your risk.

[gderf]

Thanks.  Would you mind pointing me in the right direction on how to direct forward the Ipkall # to the Obi?

See: https://www.obitalk.com/forum/index.php?topic=1292.0

No idea if it works or not I have my IPKall number forwarded to my free Callcentric IP Freedom account which is registered on my OBi.

[MikeHObi]

I'm going to go off-topic here, to say that, on the Google Voice Forum, we regularly try to discourage people from using GV for business purposes.  There's no direct customer support from Google, and when things go wrong (like this, or worse, when your clients can't reach you), it can damage your business financially, and damage your reputation for responsiveness.  Decide if the small amount of money saved is worth your risk.

FYIW in some areas it may not be even close to a small amount of money saved.

I have had the slow call resolution issue occur on both my Callcentric and Anveo services.  I grabbed an IPKall number and that one has been reliable.  Perhaps because the number i grabbed had been previously used as a forward for google voice.  As when I tried to add that number to GV as a forward, I had to capture it from someone who had that number already setup on GV. 

So right now I'm working with GV forwarding to IPKall  which is hooked to Callcentric.  sorry it is still not working for others.  you can always go without the Caller Name and use the google chat hookup.

[carl]

  Localphone in my opinion remains an excellent choice for outbound calling but it offers no bells or whistles for inbound routing.  That is why I choose to use them as an outbound only service.

Ther only real problem with incoming on Localphone is IMO the fact that you cannot retrieve your voice mail from any other phone than your own IP phone or via internet. Other than that, their DID's both national and international are excellent( land line quality on my overseas DID's) and for a small fraction of the price other providers charge.

[carl]

I believe it is because the problem may exist in the choice of call routing between Google's local exchange carrier (CLEC), and Callcentric's CLEC, http://www.telengy.net that owns the blocks of DIDs CC is issuing for free.  CC leases their paid DIDs from several other CLECs (depending on the location of the "rate center" or local calling exchange of the DID).  It's always possible that those DIDs will suffer the same fate at some point, but there haven't been any reports of problems so far on CC's paid DIDs.

There has been a thread on DSL forum's voip chat to this matter, with excellent contributions and explanations from a senior IT guy from Callcentric posting under acronym Iscream. check it out.

[SteveInWA]

I read that thread over on DSL reports.  I wouldn't call it "excellent".  IMO, there's more emotion than productive information.  While I agree that Google needs to step up and work with their CLEC to diagnose and cooperatively solve the problem, the part that "Iscream" is indignantly ignoring is that they've either created their own little CLEC (Telengy) or they have some sort of business relationship with it.  Think about it:  there is no such thing as free beer.  Why would they give away those DIDs?  They're leveraging that CLEC to make some money on the inbound call interconnection fees, and it isn't exactly a world-class CLEC...free means cutting corners and using the cheapest possible routes.  It's not surprising that Google's CLEC might be reacting to that by also using some low-grade/low-cost route to connect.  Some of those routes have been known to not pass CID at all, or to mess it up, which is exactly what's happening.  I am not an apologist for either side; I just don't feel the same sense of outrage as Iscream...their paid DIDs work just fine.

This is an interesting case study in the free-market and lightly-regulated consequences of deregulating the telephone network.  We now have a "you get what you pay for" marketplace, instead of a monopoly, but some people still feel entitled to 1st class service at bargain-fare prices.  Millions of people jumped all over MajicJack when it came out.  MJ planned to make money on targeted advertising and interconnection fees.  The former fizzled out (ahead of its time), and I dunno how much money they make on the latter.  The result is that they raised prices and cut corners dramatically, like refusing to connect to many other carriers who charge higher interconnect fees (not to mention the world's worst customer support).

IMO, this GV<-->CLEC<-->CLEC<-->CC problem won't get resolved soon, because of the arm's-length way Google works with its CLEC, for legal/regulatory reasons.  Google may or may not feel it's important to nag their CLEC to deal with what is really a very small percentage of their user base.

[MikeHObi]

If anything this highlights the value that local telephone companies have provided.  This morass that is the interconnecting of telephone signals is simply that, a morass.  Google has almost if not completely zero motivation to do anything about it because whatever value they received from Grand Central purchase has nothing to do with all of use people using the voice service. 

I wish they would fix the problem.  But somehow I get the feeling that they just don't care.

[lhm.]

@MikeHObi

I have the same setup and get CID but not Cnam (IpKall > 1777XXXXXXX@in.callcentric.com). Do you get Cnam inbound? If so how are you setup from IpKall?

[carl]

They're leveraging that CLEC to make some money on the inbound call interconnection fees, and it isn't exactly a world-class CLEC...free means cutting corners and using the cheapest possible routes.  It's not surprising that Google's CLEC might be reacting to that by also using some low-grade/low-cost route to connect.  Some of those routes have been known to not pass CID at all, or to mess it up, which is exactly what's happening.  I am not an apologist for either side;

It would need some good explanation what a terminating carrier like Telengy has to do with routing, incoming signalling and all of that.

[SteveInWA]

They're leveraging that CLEC to make some money on the inbound call interconnection fees, and it isn't exactly a world-class CLEC...free means cutting corners and using the cheapest possible routes.  It's not surprising that Google's CLEC might be reacting to that by also using some low-grade/low-cost route to connect.  Some of those routes have been known to not pass CID at all, or to mess it up, which is exactly what's happening.  I am not an apologist for either side;

It would need some good explanation what a terminating carrier like Telengy has to do with routing, incoming signalling and all of that.

Regardless of your desire for an explanation, the fact is, that calls routed from Google's CLEC to Telengy are either corrupting or losing caller ID or not being connected.  Google and Callcentric are now aware of this fact, and they're trying to resolve it.  Calls routed from Google's CLEC to other carriers (ILECs or CLECs) are working as expected, with a few periodic exceptions caused by LNP or inter-carrier routing errors.

[SteveInWA]

@MikeHObi

I have the same setup and get CID but not Cnam (IpKall > 1777XXXXXXX@in.callcentric.com). Do you get Cnam inbound? If so how are you setup from IpKall?

As you may be aware, CID is (supposed to be) passed along with the call setup by the originating carrier.  So, as long as it isn't broken (like it is with the GV-->Telengy situation at the moment), and as long as the originating caller hasn't blocked it, you'll get it at the terminating end.  CNAM, on the other hand, is not transmitted with the call, but instead, is obtained via a database lookup by the terminating carrier during the ring period.

IPKall, being a free service like Google Voice, doesn't pay for CNAM -- it isn't doing the CNAM lookups.  So, you won't get CNAM via IPKall.  CC does do the lookups for its DIDs, even their free ones.

[lhm.]

"IPKall, being a free service like Google Voice, doesn't pay for CNAM -- it isn't doing the CNAM lookups.  So, you won't get CNAM via IPKall.  CC does do the lookups for its DIDs, even their free ones."

It appears forwarded GV calls via IPKall to CC (free DID) via SIP will not show CNAM just CID. At least not for me.