OBiTALK Community

General Support => On-Topic: Obihai and OBi Products => Topic started by: wpbear on February 09, 2014, 09:47:29 PM

Title: CID Problem
Post by: wpbear on February 09, 2014, 09:47:29 PM
I have setup GV to IPKAL to Localphone to Obi100.

If I dial GV the CID shows a random 206 number.

If I dial the IPKALL # direct then I get the actual CID number as I expect.

My IPKALL # is a 425 area code not 206.

This is a new problem in the past few days, it was working with proper CID for the past few weeks.

Title: Re: CID Problem
Post by: gderf on February 10, 2014, 05:52:26 AM
I have seen this a few times, it comes and goes.
Title: Re: CID Problem
Post by: wpbear on February 10, 2014, 07:45:43 PM
If I wanted to port my GV # out so I can keep my GV #; where is the cheapest place.  So tired of Google messing things up.
Title: Re: CID Problem
Post by: cluckercreek on February 10, 2014, 07:54:29 PM
Obivoice is porting GV #'s for free with their service. You can't get cheaper than free. ;D
Title: Re: CID Problem
Post by: jazzy on February 14, 2014, 07:25:00 PM
Quote from: wpbear on February 09, 2014, 09:47:29 PM
I have setup GV to IPKAL to Localphone to Obi100.

If I dial GV the CID shows a random 206 number.

If I dial the IPKALL # direct then I get the actual CID number as I expect.

My IPKALL # is a 425 area code not 206.

This is a new problem in the past few days, it was working with proper CID for the past few weeks.


I have the same problem right now.  All calls to GV > IPKALL# show CID as 206-682-0185
If I call my IPKALL # directly, the CID is correct.  This started happening this past week, prior to that
calls to GV>IPKALL# were passing the CID correctly.  Is this now a permanent thing? or will it clear up and start to work again.  My IPKALL # is area code 206.  I read somewhere that the 206-682-0185 is a GV #.  Which meant that  my original GV CID got mangled when forwarding to IPKALL.  Is that
what's happening? 
Title: Re: CID Problem
Post by: gderf on February 14, 2014, 07:27:44 PM
I am seeing this also, but it's not happening all the time.
Title: Re: CID Problem
Post by: wpbear on February 17, 2014, 10:53:38 AM
That's the same number my CID has been showing.
Title: Re: CID Problem
Post by: MikeHObi on February 18, 2014, 12:02:19 PM
For now I have just switched to forwarding to google chat with voice and will live without CNAME.  Google voice has become just way too unreliable with forwarding to both Callcentric and Anveo.  For the past 2 weeks I've been having it forward through Anveo had numerous reports of call termination problems.  I'm jealous of those not experiencing similar issues.  I think for the home line I'll probably just port the GV number down to Anveo when it comes time.
Title: Re: CID Problem
Post by: SteveInWA on February 19, 2014, 08:42:19 PM
An observation/opinion, and a suggestion:

IPKall is simply junk.  Their numbers have all been recycled through many users, often used for GV for a short time, then abandoned, creating a mess in Google's database.  Google blocks numbers after a certain number of these recycled uses, to prevent abuse of their system for spam calling, harassment, or other unwanted activity.  I have no idea why you are seeing that Seattle number as caller ID, but it is neither in Google's CLEC or IPKall's systems.  It's a former Qwest number:  http://tnid.us/lookup/2066820185/ likely ported into oblivion and erroneously being displayed.

Caller ID is sent by the first LEC to put the call onto the PSTN.  That's GV's CLEC, bandwidth.com, in this case.  IPKall is mangling it upon receipt; it's their screw-up.  Whichever ITSP you happen to use via SIP forwarding (localphone, Callcentric, Anveo, etc), is just a pass-through; they have no involvement whatsoever in altering the CID.  The fact that IPKall doesn't act as a true phone service provider, but requires sponging off of some actual ITSP, is even more reason to avoid them.

For all you folks holding out until the last minute to port out of GV:  don't wait.  Do it now.  Think about it:  porting out of GV, as it exists today, is a crap shoot.  Many users experience problems with their ported-out number remaining stuck in Google's CLEC database, interfering with the ability of inbound callers reaching the number after it's been ported.  Sometimes, this gets cleared up automatically after Google runs a periodic batch job to catch such problems.  Sometimes, it never gets fixed.  There is no customer support at all from Google to resolve these issues.

If you wait until May 15th, there will be a gigantic flood of ports-out, guaranteeing delays, even more problems, and less likelihood of getting them fixed.  You will suffer the consequences.

So, the time for action is now.  Getting stuck in the cycle searching for the cheapest, or even free phone service is foolhardy.  Pick a service provider and go for it.

*Keys to success when porting out of GV:
Title: Re: CID Problem
Post by: Johnny on February 20, 2014, 02:13:50 PM
SteveInWA,

Excellent advice.

I am doing exactly as you suggested and am porting out now.

In fact I have already ported out a few GV numbers and have run into problems doing so.

Your advice about waiting a few days after "unlocking" your GV number is great advice.  I didn't realize this, and two times my ports were rejected for not "unlocking" the number first, when in fact, I had "unlocked" the number before starting the port.

Also, as you mentioned, one of my ports didn't quite complete entirely and I had some messages and calls going to one carrier and some going to my GV account.  Finally after a lot of haggling, GV released my number and the port completed.


The GV online forums aren't much help when you have problems.

So, in conclusion, I would definitely recommend people follow your advice as to porting out now, but some folks just can't let go.

Good luck if you decide to ride it out.

Me? I'm getting off now.....
Title: Port out?
Post by: J4545 on February 21, 2014, 05:52:09 PM
I have a GV number that forwards to my office landline, my cell, and an Obi100.

I also have a Callcentric "Pay-Per-Call" number on the Obi, which gives me outgoing calls for 2 cents a minute and E-911.

Finally an Android Talkatone free number that is yet another destination for GV calls.

Obi says: "...your OBi will continue working as it does today – with calls to your Google Voice number ringing the phone and use of Google's service for connecting calls to the numbers you dial."

When XMPP goes away I was hoping I could just forward GV to the Callcentric number on the Obi.

So is there some reason I need to port my GV number?

Thank you very much for any info and suggestions.

Title: Re: CID Problem
Post by: gderf on February 21, 2014, 06:29:21 PM
Quote from: J4545 on February 21, 2014, 05:52:09 PM

When XMPP goes away I was hoping I could just forward GV to the Callcentric number on the Obi.

XMPP isn't used to do this now, so the end of XMPP is irrelevant for this aspect of your service.
Title: Re: CID Problem
Post by: J4545 on February 21, 2014, 06:36:04 PM
My understanding is my Obi will no longer say "SP1:  Google Voice™ Account" after May. I thought that was because it used XMPP to make that connection to GV.
Title: Re: CID Problem
Post by: gderf on February 21, 2014, 06:38:40 PM
Once XMPP is shut down, you can delete your SP1. Forwarding GV to a DID doesn't use XMPP or your SP1 that is configured for GV.
Title: Re: CID Problem
Post by: J4545 on February 21, 2014, 06:44:58 PM
Great, that's what I thought. So I'm still not seeing any reason to port out of GV.

From GV's point of view it is just going to keep on forwarding my number to various phone numbers. I would rather have my total system decoupled into independent components anyway.
Title: Re: CID Problem
Post by: gderf on February 21, 2014, 06:48:24 PM
There is no reason to port out of GV for incoming calls so long as you have one or more forwards to one or more DIDs that work to your satisfaction.

The larger problem is making outgoing calls with GV once XMPP is shut off.
Title: Re: CID Problem
Post by: J4545 on February 21, 2014, 07:29:26 PM
Thanks all for the clarifications.

Nothing is free. If it appears to be free, then it is a loss-leader or a market exploration and data collection effort. I always knew GV would change or even go away completely.

I think I can somehow survive paying Callcentric 2 cents a minute when I want to make a call from my Obi ;) Just the entertainment value of a build-your-own communication system is worth it.
Title: Re: CID Problem
Post by: gderf on February 21, 2014, 07:35:57 PM
You can do better than 2 cents a minute just about anywhere. In some case a lot better.
Title: Re: CID Problem
Post by: carl on February 21, 2014, 08:24:19 PM
Quote from: J4545 on February 21, 2014, 06:44:58 PM
Great, that's what I thought. So I'm still not seeing any reason to port out of GV.


Hmm, have you read other postings/threads on this and other forums?  GV, including GV forwarding , is becoming increasingly unreliable.
Title: Re: CID Problem
Post by: SteveInWA on February 21, 2014, 09:21:42 PM
Quote from: J4545 on February 21, 2014, 06:44:58 PM
Great, that's what I thought. So I'm still not seeing any reason to port out of GV.

From GV's point of view it is just going to keep on forwarding my number to various phone numbers. I would rather have my total system decoupled into independent components anyway.

I posted about porting out for this reason:  Many OBi customers bought the device expecting to use it with a Google-issued, or ported-into-GV phone number, as if GV was a "free phone company".  They may not have cared about, or made use of, the many other features of GV.  It never was a free phone company, and now that third-party direct access via XMPP is being shut down, some of those people will be unhappy.  Those people now have a choice:  port their GV phone number to an actual VoIP Internet Telephone Service Provider (ITSP), or keep the number with GV, and use a SIP VoIP carrier as a GV forwarding destination on their GV account, and on their OBi box.  One way or the other, it's time to make a decision and to take action now, not wait.

This has been discussed in great detail elsewhere on the forums.  My point was regarding timing, with some added tips for success.
Title: Re: CID Problem
Post by: MikeHObi on February 22, 2014, 04:46:50 PM
Quote from: J4545 on February 21, 2014, 06:44:58 PM
Great, that's what I thought. So I'm still not seeing any reason to port out of GV.

The reason why I plan to port out is because my experience over the past 6-9 months has been that GV forwarding to DID's from Callcentric and Anveo has resulted in extremely poor performance.  Either due to lack of CID or calls going to voice mail because google's interconnect to Aveno or Callcentric took too long.

Google has remained patently unresponsive to bug reports from users about these problems and due to that it is my belief that google voice is not a viable solution for me on my home line.  The down side to all of this is google could care less if they loose my home DID.  From their lack of response to GV problems I have to assume that they simply have no interest in supporting their GV product.
Title: Re: CID Problem
Post by: wpbear on March 02, 2014, 02:53:02 PM
I tried a new setup which is working better.

Get Free callcentric DID. On callcentric site configure the DID to always forward to xxxxxxxxxx@localphone.com:5060 (xxxxx is your localphone number)

On Google voice website add callcentric DID.

On obitalk setup sp1 to localphone using wizard.

Every test call to my Google voice has rang my home phone and had correct caller Id.

Title: Re: CID Problem
Post by: AndyJ on March 04, 2014, 07:15:05 AM
Quote from: SteveInWA on February 19, 2014, 08:42:19 PMCaller ID is sent by the first LEC to put the call onto the PSTN.  That's GV's CLEC, bandwidth.com, in this case.  IPKall is mangling it upon receipt; it's their screw-up.  Whichever ITSP you happen to use via SIP forwarding (localphone, Callcentric, Anveo, etc), is just a pass-through; they have no involvement whatsoever in altering the CID.  The fact that IPKall doesn't act as a true phone service provider, but requires sponging off of some actual ITSP, is even more reason to avoid them.
I'm seeing the same issue with IPKall numbers. If IPKall is mangling the CID, why does CID work correctly when the IPKall number is called from a (Verizon) landline, but not from Google Voice?

The explanation being given at the IPKall forum is that it's not IPKall's fault, and that a carrier somewhere along the path is changing the ANI to a number local to the destination in order to avoid higher long distance fees charged by the terminating end.
Title: Re: CID Problem
Post by: mo832 on March 11, 2014, 10:20:32 AM
My understanding from reading, waiting, and letting it sink in is that when GV incoming calls are forwarded to an IPkall DID, the caller id is screwed up. It supposedly has something to do with how well (or not) GV forwarding plays with IPkall DIDs. They sometimes don't play well together. If someone calls directly to the IPkall number, caller id usually works. If someone calls the GV DID, which then forwards to the IPkall DID, the CID is stripped (sometimes) and replaced with the 206-682-0185.
Title: Re: CID Problem
Post by: tyeske on March 11, 2014, 10:34:30 AM
I was having the same exact intermittent problem with GV to Ipkall. I switched to a free Ipcomms DID and have not had any trouble with getting the correct number to pass through.

It was definitely a problem between GV and Ipkall, but no problem with GV and Ipcomms.

Now if I could only get the name or city/state to show up, my dial plan would be perfect.