FreePBX | Register | Issues | Wiki | Portal | Support

Paging Pro Scheduler Delayed Pages?


#1

I’m working on setting up our school bells to broadcast via Mutlicast to overhead speakers.

I’ve set up the scheduler with times, but the bells are triggering on a delay…sometimes up to 30 seconds it seems…with only 3 minutes in between classes, this poses a significant challenge.

Is there any way to increase processing resolution?

Edit: This is on a fully up-to-date FreePBX 14 official distro running on ESXi


(Dave Burgess) #2

This sounds like a job for /var/log/asterisk/full extracts.


#3

Here is a bell scheduled to trigger at 10:11:00am https://pastebin.com/HwLpg5uV (end of class)

Here is another bell schedule to trigger at 10:14:00am https://pastebin.com/AMyw0980 (beginning of class)

Asterisk isn’t even beginning to setup the page until 20+ seconds after the scheduled time.


(Lorne Gaetz) #4

Are you finding the delay to be variable between tests, and more specifically is it a random value between 0 and 30 seconds? If so, it is probably due to recent changes in Framework that deliberately introduce a random delay in cron tasks. This delay is to mitigate complaints from users with VM hosts with multiple PBX instances, so they don’t have cron tasks running concurrently at the top of the minute leading to cpu spikes.

If this is the case, I can’t think of a work around, but I recommend putting in a feature request to allow control over the amt of random delay with an advanced setting for these type of situations:
https://wiki.freepbx.org/display/SUP/How+to+open+a+feature+request


#5

Yes, it is definitely variable between 0 and 30 seconds.

I understand introducing a delay for most cron tasks… however, tasks that can be scheduled by end-users like paging schedules should be honored at the top of their defined minute…with as-near second resolution as possible.

This is a really annoying change in Framework imo…especially because an advanced setting wasn’t part of the original implementation of it.

For things like school bells, this is going to pose a significant problem until this is solved. 30 seconds might not seem like a lot, but when students only have 3 minutes to get to class, 30 seconds is a VERY long time.


(Dave Burgess) #6

The problem here is that FreePBX is trying to serve many masters, so having all of the cron jobs hit at the top of the minute was causing call drops and other problems because of the flood of jobs.

A simple solution would be to add a small “cron” server on a NetBSD or Ubuntu host that executes the calls remotely from the phone server. This way, we keep the “anti-logjam” code in core and you get the cron top-of-minute fidelity you are looking for.


#7

Hardly anything simple about your solution.

The whole point of Paging Pro is having a GUI that is easy to manage…I’m not expecting to train our school’s facilities manager on how to configure the bells via ssh.

Undermining the reliability and integrity of cron is not the solution imo.

My humble recommendation is that this needs a proper solution ASAP. Running yet another VM is not a solution. I understand the idea behind randomly delaying cron jobs. However, tasks that are scheduled by your users should be processed immediately. Otherwise, the user experience is terrible.


(Dave Burgess) #8

Lorne gave you the long-term solution. Put in your request and make your case. His suggestion of a custom randomizer setting (0 to 30) would probably be close to a one-line change, and could make it through QA reasonably quickly.


(Chris Dolese) #9

please open a commercial module ticket or contact me and ill do it on your behalf

we can push the commercial module ticket faster than something landing in the community issue tracker


#10

I have created the ticket. ID 915872

Thanks,


(Jared Busch) #11

This issue is similar to what happened with my ticket from a year or so ago to attempt to get Yealink phones modified to not always reboot when a new config is pushed from EPM.

Developers took the posted issue and made a change without a cohesive thought for the rest of the ecosystem.

In my case instead of adding a new context to send a different SIP notify, they simply changed the existing [reboot-yealink] to not actually reboot. Leaving the thing doing something other than what it is named.

I blame myself, after the fact, for not posting a more thought out bug report.

This change to cron stuff is similar. It should never happen if there is only one cron for all the things.

If an admin uses time conditions and calendars to change call flow on a schedule, does that now mean those are also varied by 30 seconds?

System crons for status or health or anything else are not important crons. Those can run whenever.

But when an admin schedules a task for 5:02 and 5:05, those need to fire at exactly 5:02 and 5:05.

Edit: The same thing also happened with the change to the IVR functionality. It asn’t until it was posted here in the community that they stopped and added the “Legacy” handling for digit matching.