How does Obi Get MWI?

[thetoad30]

Can anyone tell me how the OBI is set up to get the message waiting indicator (stutter dial tone and light on phones)?

I am trying to set up an IP phone (Cisco SPA504G) to utilize the light and indicator, but I apparently don't have the proper settings because the light and stutter is either always on or always off.

Any help is greatly appreciated. I am using Vestalink as my provider. It is working properly on my OBI 202.

[SteveInWA]

Your post is ambiguous.  You said "Any help is greatly appreciated. I am using Vestalink as my provider. It is working properly on my OBI 202."

Do you mean that Message waiting works with some analog phone plugged into your OBi 202, in other words, that the OBi + Vestalink will successfully enable the stutter tone and blinking light on the analog phone?  

If so, then do you mean that you are trying to separately configure the Cisco IP phone (register it, by itself, to Vestalink, and not through the OBi)?

OBi devices turn on MWI (stutter tone) and VMWI (blinking light) if you have the options enabled for the service provider(s) that are sending the signals.  The same would be true for your Cisco phone.

If it's a non-OBi question ("How do I enable MWI features on my Cisco IP Phone?"), then, according to the admin guide for that phone, (I viewed it here:  http://www.voipsupply.com/downloads/dl/file/id/5711/cisco_spa504g_administration_guide.pdf

You can configure the message waiting indicator (MWI) for separate extensions on
the phone. The MWI lights based on the presence of new voicemail messages in
the mailbox. However, if the indicator at the top of your Cisco SPA300 Series or
Cisco SPA500 Series IP Phone is not lighting when voice mail is left, or you are not
seeing message waiting notifications on your WIP310:
STEP 1 Log in to the configuration utility.
STEP 2 Click Admin Login and advanced.
STEP 3 Click the Ext <number> tab.
STEP 4 Under Call Feature Settings, in the Message Waiting field, choose yes.
STEP 5 Click Submit All Changes.

If you meant something else, then please supply more specific information.

[thetoad30]

I am trying to configure my Cisco IP phone direct to Vestalink. My current OBI is configured direct to Vestalink as well, and the analog phone I am using is sensing the stutter tone and light.

I have read the manual for the phone. I cannot get it to work. When I select "yes" and turn on Message Waiting, it leaves the light on all the time and a stutter tone all the time. If I select no, it is always off.

I'm trying to determine how the OBI interprets, or gets, or subscribes to, the MWI of the VoIP provider. I have tried using a trace with PhonerLite direct into Vestalink, but it, too, cannot see the MWI.

I can only therefore suspect that perhaps there is something "built in" to the OBI that is automatically getting the MWI settings, and that I don't have those settings properly set up inside of my BYOD devices.

[SteveInWA]

On the OBitalk portal, expert configuration mode, it's under Voice Service, SPx Service, in the Calling Features section, and the two values are MWIEnable and X_VMWIEnable.

[SteveInWA]

There are also some MWI Subscribe settings under Service Providers, ITSPx SIP, but I have never needed to enable them.  Without some help from Cisco support (good luck), I don't know what else you could do to understand which of their settings corresponds to the OBi's settings.

[thetoad30]

I understand that.

I'm looking for deeper settings that the OBI is interpreting from any kind of "signal". My Cisco device and the PhonerLite softphone doesn't "know" how to get those messages - my question is why?

What is the OBI doing/subscribing to/interpreting to figure out that there is or isn't a message waiting?

Why is my OBI interpreting the signal, but my Cisco or PhonerLite can't? That's the piece I'm missing.

[SteveInWA]

There are two methods that the OBi can use to learn about MWI -- unsolicited NOTIFY and SUBSCRIBE.  The method that will work depends on the SIP VoIP carrier involved.  With Callcentric, for example, there's no need to enable SUBSCRIBE, since the Callcentric VM server is sending the MWI NOTIFY message when there's a message.  If your ITSP doesn't provide that service, then the user agent (OBi or Cisco in your case) needs to enable the SUBSCRIBE method, which requires knowing the ITSP's VM server's address, etc.  So, if your OBi is toggling the MWI off and on, and you haven't enabled SUBSCRIBE (I bet you didn't, since you wouldn't know the parameters to enter), the OBi is listening for the unsolicited notify messages.

There's more about this in the OBi administration guide.  Search the PDF on "MWI"

Everything you want to know about SIP and MWI in a Cisco SIP environment is here:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/12-4t/sip-12-4t-book/voi-sip-mwi.html#GUID-E887F03B-2957-4D82-AAFF-88E14D53FABA

[SteveInWA]

Bottom line:  I would expect Vestalink to provide some help and tech support for enabling this feature on your IP phone.

[thetoad30]

Thank you for that explanation.

I do believe somewhere the OBI is subscribing - looking at this URL:https://intelafone.desk.com/customer/portal/articles/1413429-mwi-on-obi-stuttering-dial-tone-message-waiting-notification

What I can't tell is where the OBI is subscribing to...

And I agree - I'd hope that Vestalink would provide support, but then in a support e-mail they stated they don't support customer devices... which is really weird, considering they are set up and have BYOD in their title and product descriptions...

[SteveInWA]

As an experiment, why don't you get a free NY DID from Callcentric, along with their free voicemail, and see if MWI/VMWI works on your IP phone?  I use Callcentric on an OBi, a Grandstream ATA, and a Gigaset IP phone system, and all of them correctly handle MWI.

[thetoad30]

I did exactly as you suggested (was a great idea - I didn't know I could get free DID and incoming calls with voicemail).

It, of course, worked flawlessly with no additional configuration on my end.

So I went back to Vestalink and showed them my findings - they either didn't understand what I was looking for, or had a lot more complaints after the last time I contacted them, because they stated they are aware of the issue and are looking into it.

I really appreciate your help - that last troubleshooting step you provided me stopped me from ripping the rest of my hair out!