Voicemail notification and MWI erratic behavior

General Help
1

On occasion, an extension will receive a voicemail(s) but will not notify the user either via the screen or MWI. Then, after a period of time the user will receive the notification and the mwi will light up. If the user does not check the new voicemails, the notifications may disappear for a period of time then return. Rebooting the phone will immediately show the new voicemail notifications.

Below is hopefully some useful info pertaining to our setup in relation to this issue. Happy to provide any additional logs or settings. Thanks for looking

PBX Firmware: 12.7.5-1807-1.sng7
Asterisk: 13.22.0
All phones: Yealink T29G firmware 46.83.0.35
We are not running the commercial module Voicemail Notifications.
We have two trunks connected via chan_sip and all extensions are pjsip

Freepbx extension settings:
Extension ā†’ Advanced: MWI Subscription Type = Auto

MWI basefile settings for yealink template in EPM:
account.1.subscribe_mwi = line1Mwi
account.1.subscribe_mwi_expires = 3600
account.1.subscribe_mwi_to_vm = 0

screenshot of related t29g phone settings:
t29g_mwi

2

An additional voicemail oddity that has been occurring, is sometimes a user will get a notification that there is a new voicemail(s). However logging in to vm and checking shows that there is not. After a period of time the notifications disappear, or may reappear. Does not happen often or with many users at a time. Just the odd one or two users.

Furthermore, our receptionist extension does not have a voicemail box created. But sometimes that extension will all of a sudden show new voicemails. A phone reboot will cause them to disappear, but they may or may not return.

From the lack of notifications as described in my first post, I would initially think this would be some sort of a subscription issue. But then that theory doesnā€™t really work with my second post on where ā€˜phantomā€™ voicemails appear.

Any one have any ideas or suggestions to try? Any particular logs that might offer a clue? Could this be some sort of weird pjsip issue?

Thanks.

3

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

5

So I actually witnesses this behavior on my own extension today.

Call came in at 11:11 which I ignored and caller left voicemail which I never checked. Phone MWI light came on and screen displayed missed call and voicemail icon.

By 12:13 I glanced at my phone and noticed MWI light was off, screen displayed missed call but no longer had the voicemail icon. Logged into FreePBX and could see the new voicemail in my inbox.

At 12:48 phone played the stutter tone when a user has an unchecked voicemail, I looked over but no MWI or screen icon.

At 1:36 head stutter tone again, looked over more quickly and saw the screen displaying 1 new voicemail but then immediately went back to normal wallpaper with no notification.

At 2:37 rebooted phone, MWI came on and voicemail icon displayed.

After an unknown period of time I lost the MWI and voicemail icon again.

So I was curious if during this period of behavior if any extension with a voicemail would behave the same. So I have a test extension on my desk, I called it and left a voicemail. MWI and voicemail icon came on as normal. There was a few updates available, so I updated and reloaded asterisk. Rebooted both phones, and voicemail notifications came on as expected. I left for the day.

At 0900 this morning phones woke up from sleep. My extension is still showing MWI and voicemail icon. The test extension is only showing voicemail icon, the MWI turned off at some point last night.

By 925, test extension also lost the voicemail icon.

Is there a methodology where I can see when the phone makes a request to the server for voicemail info, and to see the response from the server? Obviously it initially works, but then why does it lose it?

I pulled a syslog from the phone, and I can see where it recognizes a voicemail from the server, then seconds later is does not then tells the gui. I will post a snip below.

At this point I donā€™t know if this is a phone issue, asterisk issue or perhaps a channel driver issue. In trying to eliminate something, I have converted the test extension over to chan_sip. It immediately recognized a new voicemail along with MWI and gui icon. Iā€™m just going to let it sit and see what happens.

6

As mentioned above, here is a heavily trimmed portion of the syslog from the phone.

Dec 21 17:17:32 192.168.0.137 Dec 21 17:17:33 sua [1326]: DLG <6+info  > [000] Messages-Waiting: yes  
Dec 21 17:17:32 192.168.0.137 Dec 21 17:17:33 sua [1326]: DLG <6+info  > [000] Voice-Message: 1/0 (0/0)  
 
Dec 21 17:17:32 192.168.0.137 Dec 21 17:17:33 GUI [1307:1307]: ACCU<6+info  > 253.492.416:Voice Mail new[1] old[0] 
Dec 21 17:17:32 192.168.0.137 Dec 21 17:17:33 GUI [1307:1307]: ACCU<6+info  > 253.493.919:Voice mail count no change 

Dec 21 17:45:22 192.168.0.137 Dec 21 17:45:23 sua [1326]: DLG <6+info  > [000] Messages-Waiting: yes  
Dec 21 17:45:22 192.168.0.137 Dec 21 17:45:23 sua [1326]: DLG <6+info  > [000] Voice-Message: 1/0 (0/0)  

Dec 21 17:45:23 192.168.0.137 Dec 21 17:45:24 sua [1326]: DLG <6+info  > [000] Messages-Waiting: no  
Dec 21 17:45:23 192.168.0.137 Dec 21 17:45:24 sua [1326]: DLG <6+info  > [000] Voice-Message: 0/0 (0/0)  

Dec 21 17:45:23 192.168.0.137 Dec 21 17:45:24 GUI [1307:1307]: ACCU<6+info  > 924.711.093:Voice Mail new[0] old[0] 
Dec 21 17:45:23 192.168.0.137 Dec 21 17:45:24 GUI [1307:1307]: ACCU<6+info  > 924.716.845:CAccountManager::SetLastVMailAccountID(iAccountID = -1) m_iLastVoiceMailID = -1 
Dec 21 17:45:23 192.168.0.137 Dec 21 17:45:24 GUI [1307:1307]: ACCU<6+info  > 924.718.089:uLastNewVoice[1] uNewNumber[0]
7

Are the phones local to the PBX or are they remote?

8

Hi Tom. Entire system is local and on the same subnet. Thanks.

9

Do you see the PBX send the NOTIFY to the device when a new voicemail is being left? Or after a voicemail has been deleted/moved from the INBOX?

10

When using ā€˜asterisk -rvvvvā€™ and ā€˜sip set debug onā€™ I can see the process of the call go thru to voicemail and the recording being made and saved on the server. Iā€™ve been unable to find/decipher the line of code the server uses to notify the extension. Am I looking in the right place, and is there a specific line I can search for? I searched for NOTIFY in the full log during the time I left and deleted a voicemail but all I find is:

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE

11

So I changed test extension over to chan_sip, left new voicemails on both the test and regular pjsip extension, restarted asterisk and rebooted phones. Both phones popped up with new voicemail icons and MWI. I left the phones as is and left for the day.

Returned to office after about 38 hours, test extension on chan_sip still showing new voicemails pending. Other extension on pjsip showing no new messages. Ironic, as that pjsip extension actually received more new voicemails while I was out.

So Iā€™ve ran a syslog on the pjsip phone for the last 5 hours. Every 90 min I can see where the phone is told by the server there are new messages, then within seconds phone is informed there are none. I suppose that explains the stutter notification and flashing of voicemail icon/MWI that immediately disappears that I mentioned in a post above.

I donā€™t know enough to decipher this any further. Perhaps phoneā€™s firmware has some sort of problem with asterisks reply when connected via pjsip channel? I have submitted a case with Yealink, they suggest it is asterisks replies that are causing this behavior.

Iā€™m going to convert the other extension to chan_sip while leaving the new voicemails and see how it behaves for the next few days while out for the holidays.

Happy Holidays to all.

12

And these extensions are on two different phones, correct? Not the same phone?

13

That is correct, two separate phones. To further prove to myself that this seems pjsip related in some manner, I converted the chan_sip extension back to pjsip and the phone lost new voicemail icons/MWI within a few hours.

14

I would open a bug report with the asterisk team on this with all the captures and logs.

15

What is your version of asterisk

16

Already deep into the Egg Nog? :slight_smile:

17

The only way mwi will work reliably is if poll mailboxes is set to yes. That said thereā€™s an internal issue for mwi polling not working in 13.24+

1 Like
18

So I left both extensions on chan_sip and when I returned to the office today both where correctly displaying MWI and voicemail icons new message notifications.

I switched both extensions back to pjsip and within hours one of the extensions lost new voicemail icon/MWI notifications. So fairly repeatable results here.

I did notice that another extension in the building had received voicemails over the holidays and when I walked over and checked, it does have its MWI and voicemail icon lit up. This extension is using pjsip along with all the other extensions in the building.

I did ask Yealink if this could be a chan_sip vs pjsip issue in relation to how their firmware reacts, however they did not respond to the question and informed me they escalated my ticket to their R&D.

@tonyclewis Certainly my next stop if I donā€™t decide just to switch all extensions to chan_sip and be done.

@tm1000 When you say polling mailboxes are we talking setting Extension ā†’ Advanced: MWI Subscription Type = Yes

Thanks for the replies/feedback guys.

19

Going back to chansip would be a big mistake as itā€™s not supported anymore and getting no security or bug fixes from Digium.

20

Not disagreeing with the sentiment, but if the problem goes away with chan_sip and exists with PJ-SIP the cheapest solution (at least from a ā€˜time wasted farding around with the problemā€™ perspective) would be to switch back.

PJ-SIP is the preferred way to set this up and it has matured a lot over the past couple of years, but as long as these little one-off problems keep popping up, having and using both makes sense.

Now, having said that - there is a ā€œmiddle groundā€ that is easy to occupy. Set up the phones that donā€™t like PJ-SIP with Chan-SIP and just use both. Set up the ā€œproblem childrenā€ so they talk to port 5160 and enable both channel drivers. If you do this, itā€™s up to you to make sure you document how and why, but once done, itā€™s time you can stop wasting on getting the ā€œpreferedā€ solution working.

Over time, as we get better at using PJ-SIP and these one-offs go away, you can wean your old phones off Chan-SIP and eventually move to the new driver.