With all of the endless stream of security / kernel updates these days, it’s became very clear that for us every single time we reboot our FreePBX17 server, it breaks the Message Waiting Indicator for VM for all of our endpoints. We have about 400 endpoints, a mix of D40s, D50s, D65s, P310s and P325s. It’s impacting all of those phones. We are on FreePBX17.
The only “fix” I’ve been able to find for this is every time after the server has been rebooted, to go into Endpoint Manager, Extension Mapping, set the rows per page to 100, select all on the first page, choose “Save, Rebuild Configs and Update Phones”. Repeatt this for all 4 pages of our phones, then do an apply config. This entire process takes not exaggerating 15 minutes, with several manual steps.
Does anyone know of any better solution for this issue?
Makes sense. Funny side note about MWI. For our company sites, most users aren’t old school in terms of wanting to manually dial into the voice portal to retrieve and manage their VM messages. Over time we’d run into a lot of users with full VMB’s. So I opted for e-mail delivery instead, choosing to not having those messages accumulate in their VMB’s. Guess with Microsoft 364 in the mix for our organization, that makes for some catching up to do today. lol. Thankful for SMTP retries before finally firing off the NDR’s.
MWI comes in two forms: unsolicited and solicited. For unsolicited there is no subscription and instead a NOTIFY is just sent to the endpoint. For solicited it requires a subscription.
The BLF issue didn’t impact MWI functionality at all, completely different as the issue was at a different layer than MWI uses. We haven’t had any reports of issues in this area that I’ve seen and haven’t touched MWI in general in… many years.
The first step for this would be to determine which type of MWI it is doing (I’m not sure what FreePBX does) and get a capture of SIP traffic to see what is going on. Knowing whether TCP is in use would also be good.