MessageWaiting is on, but not getting stutter tone

(1/2) > >>

Webslinger:
- OBi202 hardware version 1.2

- 3.1.0 (Build:5285), but also tried 4972 and 4581

- using Panasonic KX-TGA750C handsets but have also tried other phones, including a corded phone (no stutter tone, regardless)

- SP1 is a SIP service (not Google Voice)

- When a voice message is left, MessageWaiting is checked in the ATA as expected. When a voice message is deleted, MessageWaiting is unchecked as expected.

- Under SP1,

MWIEnable on         
MWIEnable2 on   
X_VMWIEnable on      
X_VMWIEnable2 on
MessageWaiting on

- Under both Phone Ports,

MWIEnable   on   
VMWIEnable on

- Under SP2, SP3, and SP4

MWIEnable off         
MWIEnable2 off   
X_VMWIEnable off      
X_VMWIEnable2 off
MessageWaiting off


The Voicemail indicator used to work fine on these phones, but I can't remember what OBi20x firmware was being used.

Well, I just tried 3.0.1 (Build: 4581) and still not getting a stutter tone despite MessageWaiting being on. I was trying different firmwares since I thought this situation might be due to a firmware bug, but I've tried 3 different firmware versions now.

My question is what settings in the ATA would cause the stutter tone to not occur on phone ports despite MessageWaiting being checked under SP1? Or what conditions would cause this situation to occur?

If anyone has any helpful thoughts, I'd appreciate reading them. Thanks

Webslinger:
On 5285, I'm seeing under SP1-->Calling features

X_MWIRoute      
X_VMWIRoute

Not really sure how to use them or whether doing so would resolve this issue.

Webslinger:
Quote from: Webslinger on September 24, 2016, 11:24:47 am

On 5285, I'm seeing under SP1-->Calling features

X_MWIRoute      
X_VMWIRoute

Not really sure how to use them or whether doing so would resolve this issue.


Well, I couldn't find anything in the Obihai admin guide, and adding {ph,ph2} in both fields didn't fix the issue.
It's really weird that the phone ports don't stutter at all despite MessageWaiting being checked on.

SteveInWA:
Looking at your posting history, I believe you are using freephoneline.ca / Fongo for your SP1 service.

This is a long-standing issue with that provider.  It's not an OBi issue.

http://forum.fongo.com/viewtopic.php?f=8&t=17194&p=68630&hilit=message+waiting#p68630

Webslinger:
Quote from: SteveInWA on September 24, 2016, 11:02:10 pm

Looking at your posting history, I believe you are using freephoneline.ca / Fongo for your SP1 service.

This is a long-standing issue with that provider.  It's not an OBi issue.

http://forum.fongo.com/viewtopic.php?f=8&t=17194&p=68630&hilit=message+waiting#p68630



No, that issue you linked to is completely unrelated and is triggered by the user manually deleting voicemail in Freephoneline's web portal, as opposed to dialing *98 and deleting voicemail through Freephoneline's voicemail attendant only. MWI, after deleting voicemail via Freephoneline's web portal, is then constantly stuck on even when voicemail is deleted. The provider's server keeps sending a packet to the ATA that enables MWI over and over again. That is, in fact, a bug involving Freephoneline's web portal. Most users in that thread are confused with, perhaps, one exception. The fix for that issue requires contacting Freephoneline's technical support and requesting the user's account to be manually reset or resynced.


Instead, the issue I'm posting about involves MessageWaiting being on in the ATA when there's actually voicemail present. That's normal and expected. However, the phone ports are not producing a stutter tone when MessageWaiting is on. That's not normal nor expected. After deleting voicemail, MessageWaiting turns off in the ATA and remains off until voicemail is left. That's normal and expected. When voicemail is left, MessageWaiting turns on again (normal and expected) in the ATA, but the phone ports are not producing a stutter tone. That's not normal nor expected. I also tested with a corded phone.

Also, if I enable MessageWaiting manually and reboot, there's still no stutter tone despite the fact MessageWaiting remains checked (because I've left a voicemail while the ATA is rebooting). Consequently, I can't see how this is a provider issue. The condition of having MessageWaiting on in addition to having the following settings enabled, should produce a stutter tone, regardless of the SIP provider being used:


MWIEnable on        
MWIEnable2 on  
X_VMWIEnable on      
X_VMWIEnable2 on
MessageWaiting on

- Under both Phone Ports,

MWIEnable   on  
VMWIEnable on

The first time I noticed this issue is after updating to 3.1.0 (Build:5285). I'm also not using the Obitalk.com web portal. I mention this because I don't see X_MWIRoute and X_VMWIRoute in Obitalk.com, under SP1-->Calling Features. I have Obitalk provisioning disabled, and I'm making changes directly in the ATA instead.

It's the SIP server's job to enable MessageWaiting in the ATA when voicemail is present. The server does that properly. And it turns off MessageWaiting in the ATA when voicemail is not present. The provider is doing its job.

It's the ATA's job to produce a stutter tone on the phone ports when MessageWaiting is on. The provider is not responsible for producing the stutter tone.

So, unless I'm misunderstanding something, I can't see how this issue I'm describing has anything to do with the SIP provider being used on SP1.

Possibly some setting is messed up in the ATA, but I'm really hoping not to have to reset the thing back to defaults. I'm hoping someone can tell me what settings to look at. And it would be great if someone would describe what X_MWIRoute and X_VMWIRoute do, and how to use those settings (i.e, the syntax required for them).

FWIW, Freephoneline is not Fongo Home Phone. Fongo Home Phone is not a BYOD service. They're two separate services owned by Fibernetics, a CLEC in Canada, which is also a carrier for VoIP.ms. I know Freephonline's website has "Fongo" and "Powered by Fongo" posted all over the place, but Fongo Mobile and Fongo Home Phone are separate services from Freephoneline.

Thank you for your time and also for trying to find an answer. I appreciate the effort.

Navigation

[0] Message Index

[#] Next page