GVE and HD2 update

Need extra help installing your Ooma Hub or Telo system? Let us know.
Post Reply
dklane01
Posts: 5
Joined: Thu Dec 06, 2012 6:36 pm

GVE and HD2 update

Post by dklane01 » Thu Dec 06, 2012 6:46 pm

Hello,

I haven't been on in quite awhile, but now with the HD2 and Linx devices I started using the Telco much more again.

Love the new setup with multiple lines and setting up a private account. Setting up GVE isn't working exactly right... it doesn't ring my voicemail correctly, but I actually like the way its working - outbound caller ID is the GV number, but people can call the GV number or the underlying virtual number and it rings... if I remember right this is a bug in provisioning, but if you fix it, it stops the virtual number from working, so it can stay how it is.. ;)

The only thing I would like it the latest system update for the HD2 and Linx fixes. I just added both in the past couple days and the update would be nice to get.

Thanks!!

User avatar
lbmofo
Posts: 9337
Joined: Sun Mar 14, 2010 7:37 pm
Location: Greater Seattle
Contact:

Re: GVE and HD2 update

Post by lbmofo » Thu Dec 06, 2012 8:19 pm

dklane01 wrote:Setting up GVE isn't working exactly right... it doesn't ring my voicemail correctly, but I actually like the way its working - outbound caller ID is the GV number, but people can call the GV number or the underlying virtual number and it rings... if I remember right this is a bug in provisioning, but if you fix it, it stops the virtual number from working, so it can stay how it is.. ;)
This is how I know it to work. If you call virtual number tied to GVE, it will ring your Ooma but will not go to Ooma Voicemail (after so many rings, it will give busy signal); this is so that GV VM can take over.
Customer Since: 3/13/10
Hardware: Telo & Hub
Service: Premier 12/06/10
Verizon Port: 3/15/10 - 4/02/10
Internet: 100 Mbps/10 Mbps
Setup: SB6141/R6700/Ooma
MainStreetSHARES Ebates: get Ca$h Back when you shop online!!

Image

dklane01
Posts: 5
Joined: Thu Dec 06, 2012 6:36 pm

Re: GVE and HD2 update

Post by dklane01 » Thu Dec 06, 2012 8:48 pm

A
Last edited by dklane01 on Thu Dec 06, 2012 8:55 pm, edited 2 times in total.

dklane01
Posts: 5
Joined: Thu Dec 06, 2012 6:36 pm

Re: GVE and HD2 update

Post by dklane01 » Thu Dec 06, 2012 8:54 pm

lbmofo wrote:
dklane01 wrote:Setting up GVE isn't working exactly right... it doesn't ring my voicemail correctly, but I actually like the way its working - outbound caller ID is the GV number, but people can call the GV number or the underlying virtual number and it rings... if I remember right this is a bug in provisioning, but if you fix it, it stops the virtual number from working, so it can stay how it is.. ;)
This is how I know it to work. If you call virtual number tied to GVE, it will ring your Ooma but will not go to Ooma Voicemail (after so many rings, it will give busy signal); this is so that GV VM can take over.
Well, in its current state, the Ooma voicemail works and dialing the *#486 to get to gve voicemail gives a fast busy. This is exactly what I want... both voice mails working, but the outbound caller ID being the GV number.

This happened when I added the old Telo handsets, too. Got rid of those a year ago because they were horrible. Absolutely love how it all works now!


Lifetime Premier member here who took advantage of moving from the Hub right away when the Telo came out, too. Best money I ever spent!!!

User avatar
lbmofo
Posts: 9337
Joined: Sun Mar 14, 2010 7:37 pm
Location: Greater Seattle
Contact:

Re: GVE and HD2 update

Post by lbmofo » Thu Dec 06, 2012 10:11 pm

dklane01 wrote:Well, in its current state, the Ooma voicemail works and dialing the *#486 to get to gve voicemail gives a fast busy. This is exactly what I want... both voice mails working, but the outbound caller ID being the GV number.
Actually, it is *#483 (*#GVE). However, it does seem like it is broke giving busy signal.

If you call your virtual number, you shouldn't get to Ooma voicemail. It will give you busy after a while. I have my virtual number assigned to a private handset so maybe that's the difference but even if your virtual number is in the main account, calling it should not end up in your Ooma voicemail. For my private handset, if calling from outside, will end up with busy signal but handset calling virtual number will end up in Ooma voicemail (this shouldn't happen; Ooma VM associated with virtual number should not exist).

I noticed that using private handset, **0, **1 prefix still uses GV as outgoing callerid....not certain if this is the problem but this shouldn't be the case.

Using main account handset, **1 still uses GV as outgoing callerid; this definitely should not happen.

I'll ask one of the mods to look into this.

Once the bug is fixed, *#GVE to check GV VM should work okay given setup correctly.

https://www.ooma.com/app/support/google ... extensions

I tried to use my Google Voicemail with my Ooma Telo and it's not working. How can I fix it?

Your Google Voice account must be set up to allow direct access to voicemail from your Ooma Telo. You can do this by following these instructions:

1.Navigate to the Google Voice Settings page
2.Look for your Google Voice Virtual Number and click "Edit"
3.Click on "Show Advanced Settings"
4.Choose the "Yes" and "PIN required" options for the "Direct access to voicemail when calling your Google number from this phone?" setting

NOTE: If you don't have a PIN set up yet, you will need to configure it on the Voicemail & SMS settings page.
Customer Since: 3/13/10
Hardware: Telo & Hub
Service: Premier 12/06/10
Verizon Port: 3/15/10 - 4/02/10
Internet: 100 Mbps/10 Mbps
Setup: SB6141/R6700/Ooma
MainStreetSHARES Ebates: get Ca$h Back when you shop online!!

Image

dklane01
Posts: 5
Joined: Thu Dec 06, 2012 6:36 pm

Re: GVE and HD2 update

Post by dklane01 » Fri Dec 07, 2012 4:25 am

Nope, I have it setup on a private number with the HD2 only, yes it is fast busy even with *#483, mis-stated that.

I actually like this way it works better because the virtual number, which is actually a prior ported number, still gets called now and then. In fact, I wish there was an official option for it to work this way, because the only thing I really want is the outgoing CID to be the GV number, but you can't do that without turning on GVE.

I believe it works this way because I had this originally provisioned with GVE, then went back to having both numbers on the main account, had to have them fix the voicemail because the original handset was so completely horrible that I turned them all off and just forwarded the second line to a cell phone permanently while waiting for the HD2 to come out.

This is definitely not the normal behavior, but you have to essentially have them manually turn off GVE once and then you self provision again, then it gets into this state, but again, I LIKE it the way it is working.

What I really want is the update. And thank goodness the HD2 and Linx are working well, because the original Telo handset was one of the worst consumer devices I have ever owned.

Tom
Ooma Moderator
Posts: 4328
Joined: Sat Sep 05, 2009 8:07 am

Re: GVE and HD2 update

Post by Tom » Fri Dec 07, 2012 8:58 am

Entered bug15589 for *#483 not working for private HD2 handsets.
It does work for shared HD2 handsets and for a private or shared Telo device.
The problem was introduced when support for HS naming was added.

A workaround for the private HD2 is to add it as an HD1 device.
The HD2 will operate the same. The only thing you lose is your config being tied to that physical HD2.
Instead your config will be tied to a generic handset ID, but not an issue if you're not RMA-ing or
reregistering handsets all the time.

And entered bug15590 for **x not overriding the Google outgoing callerid if x matches the index of the DID
that has GVE enabled.

mattquinlan
Posts: 2
Joined: Fri Jul 05, 2013 7:51 pm

Re: GVE and HD2 update

Post by mattquinlan » Mon Jul 15, 2013 5:43 am

has bug15589 been resolved yet?

Tom
Ooma Moderator
Posts: 4328
Joined: Sat Sep 05, 2009 8:07 am

Re: GVE and HD2 update

Post by Tom » Thu Jul 25, 2013 7:35 am

bug15589 is fixed in upcoming release

Post Reply