PAID Paging Pro calendar function completely useless, dead air from Sangoma

Commercial Modules
1

I have been trying to get any kind of response out of Sangoma regarding this issue, and all I’ve got so far is dead air, so I’m going to try in the forums.

We’re trying to set up a school bell system using Google Calendar as the data source. Calendar feeds from Google ICS, set to update every 1min (though debugging proves that even this is broken, it only updates every other cycle). Paging Pro module set up to use that calendar, simple as could be.

While it triggers sometimes, I have yet to get anything even remotely close to production state. I can make changes to the calendar all I want, and in some cases if I hit the PBX hard enough (some combination of force reload calendar, saving dummy changes to the paging group and applying changes, even doing a FULL REBOOT), sometimes I’ll get the bells going off. Actually changing the calendar and expecting it to refresh and adjust to the changes is a total lost cause.

I was hoping I could just set it up with a static calendar (it’s not like we’d change it that often) and let it run, so I did that this morning and did the aforementioned FULL REBOOT of the entire PBX. The first bell didn’t happen, nor did the second, and then inexplicably the third bell did. I’m sitting here now through dead silence as the 4th and 5th bells failed to go off as well.

Between the utterly random behavior of the Paging Pro module’s calendar functionality and the utter lack of response from Sangoma, I am about to call them up and demand a refund for the module, since this one feature is literally the only reason we purchased it.

Does anybody here have any suggestions about how to get this thing actually functioning? I’ve done extensive debugging including packet traces to confirm that it’s updating the calendar from Google, watching the asterisk logs to track what it’s doing, checking the job list and forcing various sync and update jobs to run, etc. Because the module itself is encrypted, and it doesn’t have any debugging when it runs, I don’t think there’s anything I can do except hope that Sangoma will both respond and fix the thing.

At this point I’m likely to be forced to write my own scheduling code for dropping .call files into the filesystem, which is absolutely ludicrous.

2 Likes
2

I wish I had more to offer than this, but I am in the same boat, I implemented a similar use case this into my PBX 3 years ago. Specifically I built a “Test Google Calendar”(Plays recorded music via multicast)… and then a “Drill Google Calendar”(Plays prerecorded emergency drill). the previous 2 years I used it, I had no issue with testing or the drill itself. However this year when I was testing, The scheduled events were not consistently working… and even bigger yikes a rogue test page with no matching Google calendar event went off 5 minutes before the end of the workday.

I suppose my reason for chiming in and mentioning my experience is that I feel like this is something that fairly recently broke.

@omegahacker What version of FreePBX are you using?

3

Hi @omegahacker just checking here. How are you trying to get in touch? Have you opened a support ticket on the topic? Please share if you have.

4

Case 02016980 with account [email protected].

5

Because FreePBX switched to Debian since our last attempt (yay!), we did a fresh install of FreePBX 17, with the current PagingPro module version being 17.0.1.7.

6

While messing with alternate ways of trigging bells (asterisk -x ‘channel originate’ etc), I was watching logs as some the bells were supposed to fire. I have two sounds, two groups and two calendars, the main bell and a 1 minute warning. The end-of-period bell worked, and the warning worked, but then literally a minute later the start-of-period bell didn’t happen. EXCEPT there was bunch of logging as if it was in fact going off. The warning and start-of-period bell for the first period also didn’t happen.

I’ve attached full logs for the 8:29 warning (nothing), 8:30 bell (nothing), 9:15 bell (worked), 9:19 warning (worked) and 9:20 bell (nothing).
failed-bells.tgz (24.8 KB)

I haven’t had a chance to compare them side-by-side yet, I’ll do that when I get home shortly and have my proper Linux machine and tools to work with.