Google Voice Message Waiting Indicator

[MarkObihai]

It looks like google voicemail notifications have been left out with the new authentication method. I would love to get those notifications added back if at all possible.

Voicemail notifications are still available - you can enable the message waiting indication (MWI) function as follows:

EDITED

As pointed out by Taoman further down this thread, MWI notifications no longer work with Google Voice

[Boykin]

If you check the box for Message Waiting, the stutter dial tone sounds and message light stay lit all the time no matter if there is a voice mail or not. 

[avinyc]

It looks like google voicemail notifications have been left out with the new authentication method. I would love to get those notifications added back if at all possible.

Voicemail notifications are still available - you can enable the message waiting indication (MWI) function as follows:

• From the OBi Dashboard, click the name of your device
• Scroll down the device configuration page and click "OBi Expert Configuration"
• At the next page click "Enter OBi Expert"



• Select "Voice Service -> SPx Service", where SPx service is the service you have GV configured on (e.g SP1)
• Scroll down until you find "MWIEnable", "X_VMWIEnable" and "MessageWaiting" - all three are grouped together in the "Calling Features" section
• Enable all these options by unchecking the "OBiTALK Settings' box then uncheck "Device Default" then check the "Value" field to enable
• Scroll to the bottom of the page and click "submit"

Your device will restart and MWI should be enabled.

I just went through this process then made a test call, left a message and it all works.

Hi Mark,

In my last post I attached an image of my OBi202's calling features section.  It does not contain an entry for MessageWaiting, but I was able to select "MWIEnable" and "X_VMWIEnable".  Is there a reason I am missing the MessageWaiting option on my device and what can I do to get this working.

Thanks!

[ceg3]

I also don't have the message waiting option my OBi100 settings.  My new 200 arrives Monday.  I wonder if it will have this option.  Just selecting the first two items just failed to work for me.

[Boykin]

I checked my 202 and it does not have the Message Waiting option.  I only see that on the 1032s and it causes the light and stutter dial ton to remain on all the time. 

[gderf]

I also don't have the message waiting option my OBi100 settings.  My new 200 arrives Monday.  I wonder if it will have this option.  Just selecting the first two items just failed to work for me.

It's gone from my 200. Must have been removed in a recent firmware upgrade.

[SteveInWA]

The MWI and VMWI options are there, on the Voice Service page.  See my attached screenshots -- one for my 202, showing a SIP Service Provider slot and the other for my 1032, showing Google Voice as a SP.

However:  Mark, the issue is that, even with these settings enabled, they have no effect on generating MWI/VMWI signals for Google Voice as a service provider.

The question to your engineers is:  is this a bug that they're working on, or is it a limitation of the new access method for Google Voice?

[gderf]

Voicemail Notification is absent from any SP configured for Google Voice via the OBiTALK portal.

[SteveInWA]

Voicemail Notification is absent from any SP configured for Google Voice via the OBiTALK portal.

Which is what I just said.

[Taoman]

The question to your engineers is:  is this a bug that they're working on, or is it a limitation of the new access method for Google Voice?

This was posted on slickdeals by someone who emailed Obihai support asking about this issue:

Obihai's official response to me regarding the message waiting indication:

"The vmail indicator (either light or stuttered tone) is no longer a feature
that is supported on the OBi with Google Voice.
You would need to check your gmail or hangouts to find out if there is
voicemail pending."

[SteveInWA]

Thanks, Taoman!

[avinyc]

The MWI and VMWI options are there, on the Voice Service page.  See my attached screenshots -- one for my 202, showing a SIP Service Provider slot and the other for my 1032, showing Google Voice as a SP.

However:  Mark, the issue is that, even with these settings enabled, they have no effect on generating MWI/VMWI signals for Google Voice as a service provider.

The question to your engineers is:  is this a bug that they're working on, or is it a limitation of the new access method for Google Voice?

Steve,

In your 2nd screenshot, you also have the parameter "MessageWaiting" but I see it is not checked as Mark had in his example.  If you enable that setting on the 1032, it should get the MWI working on that device.  Since that option is absent from the 202, it is looking like that may be part of the problem.

[SteveInWA]

The MWI and VMWI options are there, on the Voice Service page.  See my attached screenshots -- one for my 202, showing a SIP Service Provider slot and the other for my 1032, showing Google Voice as a SP.

However:  Mark, the issue is that, even with these settings enabled, they have no effect on generating MWI/VMWI signals for Google Voice as a service provider.

The question to your engineers is:  is this a bug that they're working on, or is it a limitation of the new access method for Google Voice?

Steve,

In your 2nd screenshot, you also have the parameter "MessageWaiting" but I see it is not checked as Mark had in his example.  If you enable that setting on the 1032, it should get the MWI working on that device.  Since that option is absent from the 202, it is looking like that may be part of the problem.

No, the unchecked options with the "2" after them are to turn on the indicators on phone port 2 vs. phone port 1 (this is on an OBi 202, which has two independent RJ11 phone ports).

The test I ran was on the 1032 IP phone, which has only one phone port (the phone, itself), and it doesn't work.

As Taoman replied, Obihai has already confirmed that MWI/VMWI is no longer supported for Google Voice.

[avinyc]

No, the unchecked options with the "2" after them are to turn on the indicators on phone port 2 vs. phone port 1 (this is on an OBi 202, which has two independent RJ11 phone ports).

The test I ran was on the 1032 IP phone, which has only one phone port (the phone, itself), and it doesn't work.

As Taoman replied, Obihai has already confirmed that MWI/VMWI is no longer supported for Google Voice.

Hi Steve,  I wasn't referring to the parameters marked with a 2.  I just noticed on the 1032 screenshot you had the 3rd parameter labeled "MessageWaiting" and it was unchecked.  The 3 of them are "MWIEnable", "X_VMWIEnable" and "MessageWaiting".  No matter though, as I see that Mark edited his post to say this feature is currently unavailable.  I just found that a little strange that certain devices still had the old parameter for MessageWaiting and other devices like the OBi202 do not.

In any event, it appears there is no manual workaround.  It is a bit confusing as the capability does exist and has worked prior to the firmware upgrade.  Ooma devices do not appear affected by this problem either, so perhaps it will be fixed for us in a future update.

[SteveInWA]

The "MessageWaiting" parameter is a dynamic register that actually holds the status of, well, Message Waiting!  It's not a static setting.  I don't know why they included in the settings page, since it is useless and misleading.

You can't make a comparison at all to your Ooma device or to a SIP VoIP provider.  This issue is unique to Google Voice, which does not use the standard SIP protocol, and thus, is not sending MWI/VMWI signals the same way.

[ramjet73]

You can't make a comparison at all to your Ooma device or to a SIP VoIP provider.  This issue is unique to Google Voice, which does not use the standard SIP protocol, and thus, is not sending MWI/VMWI signals the same way.

Does XMPP even support MWI/VMWI signaling?

I did some Google searches to try to find out and the closest I could come was this post from August of 2008 which discussed it as a feature request. If XMPP doesn't support communicating those items Obihai must have been accessing that information by using the credentials (Google userid and password) that they no longer require, perhaps via a web service of some sort that requires those credentials.

That's just a guess but something other than XMPP must have been used to get message waiting status since there would be no reason to stop supporting it if it is available as part of the XMPP protocol. Or maybe Obihai is just positioning for the replacement of XMPP by Google?  

[CLTGreg]

I miss this feature but usually disabled it. I was looking at turning it back on though. The 202 would get SMS sent to the caller ID which was really cool unless you didn't turn it off at night.

[SteveInWA]

You can't make a comparison at all to your Ooma device or to a SIP VoIP provider.  This issue is unique to Google Voice, which does not use the standard SIP protocol, and thus, is not sending MWI/VMWI signals the same way.

Does XMPP even support MWI/VMWI signaling?

I did some Google searches to try to find out and the closest I could come was this post from August of 2008 which discussed it as a feature request. If XMPP doesn't support communicating those items Obihai must have been accessing that information by using the credentials (Google userid and password) that they no longer require, perhaps via a web service of some sort that requires those credentials.

That's just a guess but something other than XMPP must have been used to get message waiting status since there would be no reason to stop supporting it if it is available as part of the XMPP protocol. Or maybe Obihai is just positioning for the replacement of XMPP by Google?  

I really don't know how Obihai did it, and based on the number of times it broke and had to be modified over the years, it likely wasn't using something officially-supported.  We'll just have to wait and see if this feature reappears over time as the two companies evolve their services.

[Newbie]

Short version:
GV MWI (stutter tone and visual indication) is working fine on an OBI 200 SW 3.0.1 (Build: 4367) configured manually using the OBI 200 web interface and never configured in the OBITALK portal.

Long version:
I just got an OBI 200 that came with SW 3.0.1 (Build: 4367). I was an early adopter of the OBI 110 and after just updating the 110's firmware and getting forced into using the OBITALK gateway and the new Google authorization, I made sure to stay away from OBITALK and disabled firmware updates and OBITALK before letting the OBI 200 have internet access.
(Updated my OBI 110 fw from this thread Build 2872 http://www.obitalk.com/forum/index.php?topic=8482.0)

After manually setting up voip.ms, 2 GV lines and a free Callcentric DID using only the OBI200 web interface, GV voice mail indication, both stutter tone and visual indication, is working fine. I'll definitely avoid any firmware upgrades and will be one pissed off customer if they manage to force one. They shouldn't be able to unless they've left a hidden backdoor access mechanism.

I've been away from these forums since the first few months after the OBI 100/110 release and was appalled to find OBIHAI no longer allows firmware downgrades. On top of that they don't even seem to be providing release notes for many firmware versions. I can't find any info on the changes to the OBI 110 firmware I upgraded to or the firmware that came on my new OBI200.

As an early adopter of OBIHAI's products, I'm disappointed to see their focus has shifted so much. Even with their new business focus, I don't understand companies who prohibit firmware downgrades and avoid doing business with them whenever possible. No one is perfect and I won't accept downtime when a firmware release breaks something critical to me when a simple downgrade to a previous version could get me back up quickly.

[ramjet73]

After manually setting up voip.ms, 2 GV lines and a free Callcentric DID using only the OBI200 web interface, GV voice mail indication, both stutter tone and visual indication, is working fine. I'll definitely avoid any firmware upgrades and will be one pissed off customer if they manage to force one. They shouldn't be able to unless they've left a hidden backdoor access mechanism.

My understanding is that you will have to upgrade the firmware at some point or GV will just stop working since Google is now requiring the authorization method that is only supported by the new firmware.

You've essentially figured out a way to "stop the clock", and work around the new security requirements and firmware, but that is only a temporary solution. The changes in GV were initiated by Google, not Obihai, and IMO having GV support without MWI/VMWI indicators is still better than not having it at all.