Using Google Voice voicemail with VoIP providers

<< < (2/4) > >>

SteveInWA:
I replied in another thread that the MWI signal is sent by the telephone company to which your endpoint is connected.  So, if you're using a SIP VoIP ITSP, that ITSP has no way to know that there is a message waiting on your GV account, to toggle MWI.  It can only manage MWI for its own VM servers.  When you used Google Chat to connect to GV, the OBi was getting Google's MWI signal; now it isn't.  So, no way to do what you want.  Instead, use the Google Voice mobile app on an Android or iPhone, and/or configure GV to send you a text message when you have a new message waiting.

RE:  accessing VM, this is a bug with your SIP ITSP, not Google Voice.  You should be able to correctly spoof your GV caller ID on any ITSP that allows it, and then dial into your GV number, which will see the caller ID, and let you into your VM.  I've done this with Callcentric, Skype, the Android and iOS Vonage app, and several other services.  Some ITSPs aren't implementing caller ID spoofing correctly, (it needs to be spoofed all the way out their terminating PSTN LEC, not just via SIP), and so it isn't working for their customers.  It might also be something you've done wrong on your OBi.  As a test, why don't you unplug your OBi, then provision your SIP ITSP's credentials on a softphone (I use Counterpath X-Lite or Bria), and see if it works.  If it doesn't then it's your ITSP's fault.  If it does, it is something wrong with your OBi configuration.

Taoman:
Quote from: SteveInWA on April 17, 2014, 11:18:15 pm

RE:  accessing VM, this is a bug with your SIP ITSP, not Google Voice.  You should be able to correctly spoof your GV caller ID on any ITSP that allows it, and then dial into your GV number, which will see the caller ID, and let you into your VM.  I've done this with Callcentric, Skype, the Android and iOS Vonage app, and several other services.  Some ITSPs aren't implementing caller ID spoofing correctly, (it needs to be spoofed all the way out their terminating PSTN LEC, not just via SIP), and so it isn't working for their customers.  It might also be something you've done wrong on your OBi.  As a test, why don't you unplug your OBi, then provision your SIP ITSP's credentials on a softphone (I use Counterpath X-Lite or Bria), and see if it works.  If it doesn't then it's your ITSP's fault.  If it does, it is something wrong with your OBi configuration.


Interesting. Thanks for the info. I tried with a softphone and got the same results. So if what you say is true then there are a whole lot of ITSPs that "aren't implementing caller ID spoofing correctly." I have personally tested this with the following ITSPs that are spoofing my outgoing number with my Google Voice number:
PhonePower, IPComms, and Vestalink. They all act the same. When I dial my GV number it just rings and rings and is never picked up. If I preface the number with *67 then it will eventually pick up but I have to go through the procedure I detailed in my original post.

There have been several other posts from other people experiencing the same problem. I can't remember the ITSPs they were using but they can't all be using the same ones I tested with. I think this could be a big problem when the masses migrate off of Google Voice to an ITSP but continue to use GV as their primary number. Since you support Google Voice users over at Google you may wish to look into this further. I guarantee this is not an isolated event.

azrobert:
If you call your GV number with the same GV account, you will go directly to VM.
I believe when you spoof your GV number, Google detects the number is spoofed and thinks someone is trying to hack your account and then blocks the call.
In your GV settings you can setup a forwarding number to go directly to VM with or without a PIN. It's found under advanced settings.
If you can temporarily suspend spoofing (not block CID) or use another DID, it can be setup to go directly to VM.

Taoman:
Quote from: azrobert on April 18, 2014, 04:41:38 pm

If you can temporarily suspend spoofing (not block CID) or use another DID, it can be setup to go directly to VM.


Thanks for your input. Just for clarification this is in no way a problem for me. I have a smartphone with me at all times and get notified via text and email when anyone calls or leaves a voicemail in my GV account and then listen to the message on my smartphone.

I am just trying to anticipate potential problems come May 15th (or whenever) when thousands of OBIs will stop functioning. Specifically, I am thinking of WAF (wife acceptance factor). Consider this scenario: husband configures Obi with new ITSP and spoofs outgoing CID with GV DID and is gone all day at work. Wife is home and does not have cell phone or computer handy. Not only will she not get a stutter tone or MWI she may very well be completely unable to access GV voicemail at all (if Obi connected phone is her only option). Me thinks this kind of a situation will not pass WAF.

SteveInWA:
Quote from: azrobert on April 18, 2014, 04:41:38 pm

If you call your GV number with the same GV account, you will go directly to VM. This is configurable on your Google Voice settings page, to either go directly to VM, or to ring first and need you to barge in by pressing *
I believe when you spoof your GV number, Google detects the number is spoofed and thinks someone is trying to hack your account and then blocks the call.  Not as long as the phone number (caller ID) is being properly spoofed through the PSTN, in the same standard format as a legitimate PSTN phone number.  I have done it with many different ITSPs, and it works fine.
In your GV settings you can setup a forwarding number to go directly to VM with or without a PIN. It's found under advanced settings.  Right
If you can temporarily suspend spoofing (not block CID) or use another DID, it can be setup to go directly to VM.  Yes, good idea for troubleshooting:  set up any other working phone number as a verified forwarding phone.  Call in from that number to see if it behaves as it should


Navigation

[0] Message Index

[#] Next page

[*] Previous page