CID Problem

[MikeHObi]

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.

[wpbear]

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.

[AndyJ]

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.

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.

[mo832]

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.

[tyeske]

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.