The BETA Release of FreePBX 15

It’s officially been 7 months since our last blog about FreePBX 15 titled FreePBX 15 Alpha Now Available for Testing. Less than a week later Sangoma and Digium merged. What a journey it has been since then. Our humble team expanded two fold and progress has been happening at lightning speed. Thanks to the merger I now have an office in sunny San Diego, California!

FreePBX 15

When we started the development of FreePBX 15 around September 2017 we had high hopes for a release within six months. We announced that this release would include a redesigned backup module that would no longer require FreePBX restores to be from the same version you are restoring to (meaning in the past you could only restore 13 into 13, or 14 onto 14). However, software development never goes the way one plans for it to go.

There’s been a lot of work going on behind the scenes in getting FreePBX 15 to a stabilized release that we will explain below. If you haven’t seen our most recent blog be sure to check out: Performance Improvements in FreePBX. Additionally, during this time we were also able to release our highly anticipated Zulu 3.0 redesign and Queue Wallboard commercial modules.

Backup & Restore

Since backup’s inception on Nov 7, 2005 the main purpose of the module was to be able to backup FreePBX and restore it either on the same system or a brand new system. The way this was achieved for the past 14 years was to do a complete database dump of the FreePBX system and store that in a compressed backup file.

While doing a database dump is by far the easiest way to be able to backup a system, in the case of FreePBX it because increasingly more difficult to support restores from older FreePBX versions and sometimes even restores from the same FreePBX version. The reason being that FreePBX is a modular system and modules are constantly changing database table structures. If you load the database structure for a module from version 12 onto a module in version 15 the module won’t know what to do or how to migrate and you’ll be faced with errors that sometimes you can’t correct.

What FreePBX needed was the ability to utilize the modular system already provided to it and give the power of backing up and restoring to each module. In this model an individual module would assume responsibility for backing up and restoring all of its own data. FreePBX would no longer make global assumptions about modules.

There is one drawback to this idea. Namely that there are over 128 modules in FreePBX that need to be individually updated to support the new functionality the backup and restore module provided. Early on a decision was made that there would be no default fallback for unsupported modules because doing so would land you in the same boat as before the redesigned backup and restore.(Speaking of which, if you are a developer, supporting Backup and Restore is an easy process! Checkout the developer documentation for implementing Backup & Restore in your own modules)

Additionally, it was requested that each module should also be able to deal with restoring from legacy versions of FreePBX. This creates other technical issues in that we never wanted to load the FreePBX database dump back into our database because it would blow everything away. Our team came up with a unique solution to load the FreePBX MySQL database dump back into an in-memory SQLite database to use temporarily. Each individual module is then provided a handler to talk to the in memory database to query against it and then add the data it needs to the permanent database.

After many months of work and refinement our development team successfully updated 95% of the 128 modules and we are excited to be able to release the new Backup & Restore module for FreePBX 15 to the general public. We’ve also tested a few restores from FreePBX 14, 13 and yes, even 12 backup files and they all worked, however we know that not every FreePBX system is alike so we encourage you to run restores from older versions of FreePBX and report them to our bug tracker at

Additionally, because most of the data stored from each module are text strings, backup file sizes have been reduced significantly. The files can be so small that technically you could have FreePBX email you your nightly backup. (And we provide you with that ability in Filestore)

Learn more about the new Backup and Restore in FreePBX 15 on our wiki: Backup and Restore FreePBX 15+


Backup & Restore has always had support for Local and FTP file storage locations. About four years ago a community member submitted an Amazon S3 patch and our own Bryan Walters committed that patch to Backup & Restore. The patch allowed users to store backup packages on Amazon S3. While this worked well for a while, the original code the patch was based on unfortunately hasn’t seen very many updates and thus was hard for the FreePBX development team to maintain.

When we started the planning for FreePBX 15 we wanted to make sure that the new backup module would be able to officially support Amazon S3 through a regularly maintained library. Then we found Flysystem (Spelled correctly!).

Flysystem is a filesystem abstraction library for PHP. By providing a unified interface for many different filesystems you’re able to swap out filesystems without application wide rewrites. Using Flysystem can eliminate vendor-lock in, reduce technical debt, and improve the testability of your code.

Enter the Filestore module. A centralized place in FreePBX to manage remote or local file storage locations. Right out of the gate FreePBX File Store supports Dropbox and Amazon S3 and with demand from the community we could potentially support any other service that is a supported adaptor from Flysystem.

The best part about Flysystem is that it gives FreePBX the flexibility in the future to be able to store items like recordings, faxes and much more away from your system and into the cloud.


Somewhere along the road of FreePBX 15 we also decided to be ambitious in adding an official API based on GraphQL with the ability to use a normal RESTFul API as well. In doing so we added the ability for FreePBX to become an OAUTH 2.0 server for API authentication.

Adding GraphQL or RESTFul API calls to 128 modules is not an easy task. At this moment we have about 10 modules completed. Since the FreePBX API is mainly a developer resource we decided over time that we would add features and functionality as developers contribute or request them.

Learn more about the FreePBX API on our wiki: If you are a developer you can also learn how to allow your module to hook into API here:


If you’d like to upgrade your 14 system to BETA 15, simply go to Module Administration and check online for PBX Upgrader.

If you are the type of person that enjoys using Ansible then you’ll love that we added the ability to perform upgrades using PBX Upgrader without having to go to the GUI at all.

What’s Next?

With the release of the Sangoma 7 Distro almost 3 years ago we are finally able to provide a modern PHP version. When we started the process of bringing FreePBX to a modern supported version of PHP we had to first go to the last release of the PHP 5.x series. Both FreePBX 14 and 15 only support PHP 5.6.x. However with the release of “FreePBX 16”, FreePBX will finally have a minimum supported PHP version of 7.3. Commercial modules will also work with FreePBX 16 without the need or use of Zend. Our team is starting on this work immediately and we hope to have something to show you in the next six months.

FreePBX 13 Support
Once we have our releases of High Availability for FreePBX 14 & 15 into stable we will be sunsetting our support for FreePBX 13, so if you haven’t already start making plans to upgrade to 14 or make a backup from your 13 system and restore that onto a new 15 installation.

Parting Words

In the next few months you’ll be hearing from me again as we release High Availability 14 and announce our stable release of FreePBX 15.

Andrew Nagy, On behalf of the FreePBX Team

Performance Improvements in FreePBX

It’s been about 6 months since the engineering team last posted a blog on FreePBX and let me tell you, it’s been a busy 6 months. Last time we posted was shortly before the Digium/Sangoma merger. You’ll be happy to know that we still have a great team working on FreePBX as we did before the merger. Best of all, now that Digium and Sangoma are one team we are able to work on complex issues together that end up benefiting the open source community as a whole. Performance in FreePBX has always been a complex, multifaceted issue.

Performance problems can stem from many issues such as individual hardware, bad hard disks, corrupt ram, loading too many virtual machines on a single host. Our support team deals with so many different types of issues that it can be hard to track down the root cause at times. However there are also performance improvements that can come directly from FreePBX’s internal open source code. We will document four of these changes in this post.

Usage of AGI

The Asterisk Gateway Interface, also known as AGI, is a language-independent API for call processing. AGIs allow external scripts to manipulate Asterisk which lets Asterisk perform tasks that would otherwise be difficult or impossible.

In the world of AGIs, there are two types of AGIs actively in use today in Asterisk: AGI() and FastAGI(). Both have been in existence in Asterisk since around version 1.0. In the beginning days of FreePBX all it required was a LAMP stack; Linux, Asterisk, MySQL and PHP. To utilize FastAGI at the time meant you’d have to run a daemon that continually runs in the background listening on TCP port 4573. Additionally you’d need to effectively load all AGIs into this server at run time. Back in 2007 this was a huge mountain to climb so instead the developers of FreePBX (then known as Asterisk Management Portal) decided to use regular AGI and so was born dialparties.agi, one of the first agi php scripts to be used in FreePBX. Standard AGI is the simplest, and most widely used form of AGI. Standard AGI scripts run on the local PBX and communicate with Asterisk through socket descriptors (namely STDIN and STDOUT). The standard AGI allows for usage of all AGI commands, and is what this article will be discussing.

Fast AGI is the AGI over TCP sockets protocol. It allows for all AGI functionality except EAGI, and is provided as a solution to developers who need to run resource intensive AGI programs. By running the bulk of the AGI logic on another server, the Asterisk server itself can process calls and not worry about handling complex computation for other services. This is the recommended protocol for large applications.

Over the course of the next several years of FreePBX development, more agi scripts were added to FreePBX to do tasks that developers either didn’t want to do in Asterisk directly, or couldn’t get Asterisk to do with straight dialplan. This never caused serious issues in FreePBX until the last three years when Sangoma Support started to notice a significant impact to systems that were running for long periods of time without restarting Asterisk and had a high volume of calls. The main issue users experienced was dropped audio frames in conference rooms. This lead one of our lead engineers to open up a ticket on the Asterisk bug tracker.

With the help of the Asterisk team and our through own investigations we came to a few conclusions. First we setup a test system, against which we generated 250,000 AGI calls. This load would get Asterisk into a broken state. In this broken state the MoH will be extremely choppy, and conferences will also have dropped audio frames. After a restart of Asterisk, the MoH is no longer interrupted and conference bridges are fine.

Josh Colp of Sangoma provided more information to us:

If ConfBridge didn’t send a frame for 100 milliseconds then either every channel was blocked for that period of time (in which case you would see a flood of frames as it catches up) or the timerfd file descriptor didn’t wake up within 20ms as it was told to and instead woke up 100ms later and then resumed at a 20ms interval, or the transcoding process in the mixing loop took 100ms to execute.

Which allowed our engineer to narrow down the problem

Awesome! So, thanks to your input, it seems like we’ve narrowed down where the problem is. For some reason, that timerfd isn’t being woken up correctly when an AGI is launched.

Our engineer Rob was then able to create a few test cases by using timing test inside of Asterisk while generating the 250,000 AGI calls.

So timerfd, for whatever reason, took 5ms longer [than normal]. — Josh Colp

You’ll see that the ‘Active’ machine slipped twice. This, actually, confirms what I posted earlier — running a large number of AGI’s causes timing to slip — Rob Thomas

Rob then determined there was an issue with timerfd and Asterisk on CentOS machines.

It is an issue with the timerfd timing source freezing when asterisk uses the fork() system call to spawn an AGI. The workaround is to use dahdi timing, or, switch to using FastAGI, which does not require a fork(). — Rob Thomas

It was then determined internally that we needed to find a way to convert FreePBX modules into FastAGI. This was original no easy feat. However the code base for FreePBX references the same function call in php to create AGIs: ext_agi() what if we could use that centralized call to call fastAGIs instead:

Next we needed to create an AGI server. What we originally thought we should do was go and update all old AGIs to utilize the fastAGI server but in doing so we might break any non FreePBX Distro instances out there. Instead we came up with a way for FreePBX to be able to do a hybrid way of launching AGIs on the system and communicating with Asterisk.

The idea we had was to create a NodeJS daemon that merely does thin proxying back to Asterisk and launches AGIs just like Asterisk did. Then if this setting is enabled in FreePBX and the daemon is running to change all calls to ext_agi() to use fastagi() instead (with a call to the locally listening server).

The performance gains were nothing short of outstanding. Here is a comment from the customer who has on average 25 to 30 simultaneous calls.

The CPU still climbs from 200% to 400% depending of the lines in use (we average 25 to 30 simultaneous calls). The more lines are in use, the higher the CPU climbs and the sound gets worse.

Pre FreePBX FastAGI Asterisk at 25–30 simultaneous calls, notice the 212% CPU

Packet loss in FreePBX 14 before the implementation of the FastAGI Proxy

After our support team enabled the FastAGI server the customer sent back the following response:

I have monitored the system since last week’s update and everything seems to be working fine. We had a peak of 29 simultaneous calls this morning and the CPU did not go above 60%. At that time, I did a tcpdump and checked the stats in wireshark and I observed only 0.1% packet loss which is the best stat we had so far. At the present time, we have 24 active calls and the CPU is stable between 15% and 20% (some occasional peaks at around 60%). I think it is safe to say that the issue is resolved.

Post FreePBX FastAGI Proxy Implementation in FreePBX 14

You can enable the FastAGI server in open source FreePBX today. In FreePBX 14 it is disabled by default (but you can enable it). Once you enable it in Advanced Settings you will need to do an fwconsole reload & fwconsole restart. While in FreePBX 15 the FastAGI server is enabled by default. FreePBX 14 & 15 versions of the FastAGI server both require the PM2 module to maintain stability and uptime of the FastAGI server.

The advanced setting to enable the FastAGI Server


Dashboard Scheduler

In addition to the work we performed with FastAGI another sticking point in our cloud environments was the dashboard scheduler cron that runs once a minute. The dashboard scheduler cron is used to display statistics from your system such as the one below.

PBXact is the commercial platform for FreePBX



You can also disable dashboard scheduler in Advanced settings


However for those systems that do not want to disable the collection of system statistics the resulting queries against MySQL can be staggering. As you can see below every minute there is a huge uptick in the amount of queries to hit the MySQL server every minute.

Insert operations per second

Closer view of queries per second of different clients

After doing some initial investigations it was determined that dashboard was keeping data for over 90 days and continually reprocessing that data. So if there was data from a month ago, dashboard would take the data from a month ago and reprocess it every minute. This means you’d be continually averaging the last three months, the last 12 weeks, and the last 90 days. As you can imagine there is no point in reprocessing data from the past because it never changes. Working through the code base we were able to tell the dashboard scheduler to only update and average our most current data groupings. This means that instead of processing data from months ago you are only processing the most recent hour, day, week and month. This results in a huge performance increase to the system and a huge decrease in the amount of SQL queries per second.

Can you tell from this screenshot below when we installed the updated dashboard module?


The new dashboard module is installed at the end of the graph around 13:10



Another look at the data pre and post upgrade of the dashboard module



Data over a wider range

The most impressive stats are on the hosts as a whole. The red lines below mark when our cloud staff did a massive grouping of dashboard upgrades. You can see the drastic results below.


We immediately go from about 1.2k Queries per second to about 0.8k



Another graph on a different host shows about 1.4 kps down to 0.9 kps

These changes are in the latest versions of the Dashboard module for both FreePBX 13, 14 and 15. Respectively and

Key Value Store (KVStore)

The next big issue we noticed in regards to performance was how FreePBX’s internal Key Value Store works. The Key Value Store was introduced in FreePBX 12 as a way to store data without maintaining tables or making direct database calls.

The way Key Value Store was designed originally was that every key was stored in the same database table. The use of this feature outgrew its design as we moved from 12 and into versions 13 and 14.. In FreePBX 14 we broke out of the “1 table to rule them all” design, and made it so that the Key Value Store engine would create a separate table for each module and a separate table for values greater than 4096 bytes to optimize performance.

But there were more steps we knew we could make. Starting in Framework and Framework the Key Value Store now implements in-memory caching. This means that multiple calls to the same ‘key’ data will not make multiple calls to the database. This will create huge performance gains in code that calls the same key more than once but does not cache it locally, decreasing the amount of SQL Select calls that need to be made. Additionally, this also has the result of speeding up Key Value methods that attempt to get data in other ways, such as getting all the keys for a single module. Since the values are loaded from MySQL at first query then the keys are already in memory.

The last major benefit is that you don’t need to worry about running out of RAM with this new caching system, as anything over 4096 bytes is not stored in RAM at startup. Anything over 4096 bytes is only loaded in RAM on request.

DialParties in Dialplan

Finally, the biggest change of them all. If you know anything about the inner workings of FreePBX you might have heard of an AGI file called “dialparties.agi”. This file is launched by Asterisk for any ringgroup call or any direct extension call that has Find me/Follow me enabled. It is not considered a resource intensive file, but you can imagine the issues this file causes in terms of FreePBX’s usage of AGIs, especially when you consider there are audio cut outs due to the previously discussed AGI forking issue.

Also, developers have long wanted a way to “splice” (add) dialplan directly into dialparties.agi. Unfortunately, there has never been a way to do this unless one completely forked out the Core module.

All of this changed in FreePBX 15. In FreePBX 15 we made the effort to turn dialparties.agi into straight Asterisk dial plan. This means that every FreePBX 15 system is using the new Dial Plan Dialparties. The dialplan for dialparties can be easily hooked into by any third party module and best of all Asterisk is no longer launching an AGI for about 80% of calls. This is enabled by an advanced setting, however, it is enabled by default so you should never need to disable it.

Dialparties.agi Dialplan setting

Parting Words

As we creep closer to FreePBX 15’s release (we’ll have a blog on the status of that soon) we are proud to be able to provide these open source performance improvements. We discovered, diagnosed, and fixed these issues in our own cloud infrastructure, and are pleased the efforts will be of benefit to the community as a whole. Sangoma is proud to be supporting the FreePBX project and we look forward to providing you with more updates as the year progresses.

FreePBX 15 Alpha Now Available for Testing

It’s been a long time since we last updated you on the work in FreePBX 15. We started working on FreePBX 15 around August of last year. Throughout this time, we’ve continued to support FreePBX 14 and 13 with countless bug fixes and even a few new features. In this post we’d like to bring you up to speed on what’s been going on in FreePBX.

When we began working on FreePBX 15 our goal was to limit the number of features being added to focus on a small number of pain points we’ve repeatedly heard about from YOU! In fact, it’s your feedback that’s helped us to complete the 2 major features of this release; a reworked version of backup & restore with the ability to do between major version restores (want to back up from 14 and restore to 15? Now you can!) and a way to allow you to better integrate FreePBX into your existing workflow and processes using an API (Application Programming Interface).

FreePBX 15

Learn more about the new Backup and Restore in FreePBX 15 on our wiki:

While we’ve been quiet since January with our most recent blog post asking for additional feedback on FreePBX 15, the team has been hard at work ensuring we are able to deliver on what we promised and give everyone a chance to play with it. Without further ado, on behalf of the FreePBX and Sangoma team, we are officially releasing FreePBX 15.0 in alpha today for everyone to play with. In this alpha release, all open source FreePBX modules support the new backup & restore methods, which will allow for between major version restores. Instead of trying to group all data together in backup & restore each module is now responsible for its own data during the backup and restore process. Second, we have completed about 10 modules using our new built-in API, powered by GraphQL with more planned soon.

FreePBX 15

Learn more about the FreePBX API on our wiki

Now with that said, we also know that we asked you for feedback for what you wanted to see in FreePBX and we’ve been actively watching and listening to your suggestions. Unfortunately though, we were unable take on the added workload and really focus on any additional features you’ve ask for, but we look forward to working with the community to bring them to future releases of FreePBX.

Great, but how do I get FreePBX 15?

In the past, we’ve traditionally released an ISO and asked everyone to download and install for testing. However, we are taking a different approach this year with the hopes that it’s easier on YOU to test and provide feedback on the new functionality. This year we are releasing a version upgrade module but not through our traditional methods. Usually we release the version upgrade module via module admin, when we release our release candidates allowing customers to upgrade from the previous version, as we feel the product is close to its final release. This year we are releasing the version upgrade module at the link below which users can manually choose to download, upload and install to move to 15 and not wait for FreePBX 15 to be released as a Release Candidate. Once we feel FreePBX 15 is closer to an RC we will publish new ISOs and move the version upgrader into the module admin system in FreePBX.

However, before rushing off to upgrade your system, please note that this is NOT INTENDED FOR PRODUCTION USE. Let’s me say that one more time, please DO NOT INSTALL THIS ON A PRODUCTION SYSTEM! The version upgrade module is being provide for users to upgrade a new installation or backup of an existing system. The code will have bugs and at this point shouldn’t be relied on for production use.

To try out FreePBX 15, follow the following steps:

At this point you have done the equivalent of downloading and installing the module as if it had been available online. To complete the process, select the ’15 Upgrade Tool’ from the FreePBX Menu and follow the instructions on the screen to upgrade to the ALPHA version of FreePBX 15.

We hope you enjoy this release and that it makes working with FreePBX easier for everyone moving forward. As always, please report any issues to

Andrew Nagy, On behalf of the FreePBX Team

FreePBX 14, Distro 14 & More!

It’s sure been an amazing year here at Sangoma. We are finally proud to announce the official stable release of FreePBX 14 and also the stable release of our Enterprise Linux 7 based distro which contains many updated system libraries, not least of which is PHP 5.6.31, NodeJS 8.1.4, and Python 3.6.

Over the last 16 months, we’ve been hard at work developing FreePBX 14, and we’d like to highlight four (of the many) major improvements: Auto-Update Security Releases, Distro updates in Module Admin, Calendar Module, and an upgraded User Control Panel (UCP). To learn more about all of the new features of FreePBX 14 make sure to checkout our last blog on FreePBX:

Since then, we’ve also introduced a few major features in parallel into FreePBX 13 (that are also in FreePBX 14), the most significant one being multiple and improved directory support in User Manager. Now you can setup multiple Active Directories, LDAP directories and internal directories to control the Users that are on your PBX. FreePBX will even auto create extensions for you from your remote directories. Of course, as FreePBX is an Open Source project, this is all completely free!

You may be asking yourself “What does a new version of PHP or NodeJS get me?”. Previously in FreePBX 13 and lower we were working with PHP 5.3 and NodeJS 0.12. By requiring newer versions of these as part of FreePBX 14, apart from significant improvements in the languages themselves, the performance improvements are the most noticeable difference. This means you’ll have a snappier FreePBX on your hand, with much quicker reload times. Behind the scenes, on the back end, we are also able to utilize new libraries that also have performance improvements in themselves.

We’ve started work on FreePBX 15 which we hope to have an early release of in October 2017. Three of the most important features we are planning for FreePBX 15 is a complete revamp of our RestAPI, Backup and Restore upgrades, so you will – in the future – be able to restore from and to a different versions (Only 15 and higher, so will be able to restore – for example – 15 into 16 or 17 into 15), and a new File Store module, which will allow you to store backups (or faxes and other files) on S3, FTP, email, ssh and more!

Over the next year we will also be working on bringing FreePBX onto PHP 7.x with commercial modules.

With the release of this blog we have also released a version of the FreePBX module “Version Upgrader”, which is for standard manual, or custom installed systems, and will help the owner upgrade all the associated packages (PHP, and Node, as mentioned above). For FreePBX Distro installs we are fine tuning and checking a simple one-line command that you can run on your server to upgrade the Operating System to 7, and FreePBX to 14 at the same time, all automatically. Of course, when running this RPM your system will reboot and there will be downtime, and there are some minor prerequisites (such as a 64 bit machine, and at least 10gb of free space). As of today the distro upgrader is being released as a public beta, and more information is available on our wiki page:

Please remember, as adoption of FreePBX grows there may be things we missed. If you find any issues please open a bug at and we’ll look into it as soon as we can. You can also ask for help on our Community Forums, where you may be able to get assistance from experts in the community, too.

Thank you for using FreePBX and we look forward to what develops through 2017!

FreePBX 14 Release Candidate

It’s been over two years since the team at Sangoma set out to give FreePBX a facelift, and over a year since we completed that goal when FreePBX 13 went stable.

In the last 12 months, we’ve implemented hundreds of new features for FreePBX 13 while continuing to grow our Unified Communications product lines through Zulu. We released 6 formerly commercial modules as open source, emphasizing our support of open source. We’ve also added over 41,000 lines of new code while welcoming an additional 18 new contributors.

We also introduced Edge Mode for bleeding-edge module upgrades, support for Asterisk 14, improved reload times, self signing of modules and a new improved certificate manager that supports Let’s Encrypt. While adding all those new features, we’ve also fixed (at time of writing) 1185 reported issues.

For a full list of everything that was accomplished during our 13-release checkout our roadmap.

Making FreePBX Modern

One of the biggest problems we’ve run into over the past few years working on FreePBX 13 was the fact that we were basing FreePBX 13 around the PHP 5.3 platform. PHP 5.3 was released June 30th, 2009. With the release of FreePBX 14 we now require PHP 5.6 which was released August 28th, 2014. That’s over 5 years of improvements, which has resulted – among other things – in considerable performance improvements with 14 compared to version 13.

Due to this massive internal change, FreePBX 14 is now recommended to be installed on the Sangoma 7 distro.

Of course, manual and custom installations of all versions of FreePBX are still available, but the legacy Schmooze Distro (Cent 6.6) will not be able to upgrade to FreePBX 14 instantly, as it requires an Operating System Upgrade to Sangoma 7. More information about this will be coming in a few weeks.

Emphasizing Security

One of the first changes we made in FreePBX 14 was to let systems automatically update modules that have security vulnerabilities. This will ensure that when we release updates to modules that have security issues, your systems will be updated to prevent those security issues – in less than 24 hours! We’ve made this option opt-out, so you can disable it through Advanced Settings if you desire, but we recommend against it!

Upgrading with Ease

The days of running distro upgrade scripts or having to go deal with stuck upgrades are over. In FreePBX 14 all system upgrades are done right through the GUI, in the same place you’d normally go to update modules.

You can also schedule automatic module or system upgrades at specified dates and times.

Globalization & Localization Improvements

Sangoma Technologies is a global company with over 150 employees worldwide. We realized that United States of America date formats don’t work for many countries and locals. FreePBX now comes with the ability to define the time zone, language and date/time formatting system wide, per group and/or per user.

Each user can also individually define and change these settings from within UCP. FreePBX 14 now also supports a broader scope of UTF8 which means you can now save settings in FreePBX with emojis!

Introducing The Calendar Module

For a long time, we’ve heard different scenarios of complex time conditions logic to deal with holidays such as Easter (which falls on a different day every year).

To solve this in 14 we implemented a calendar module. This module allows you to add any web based iCal, CalDav, Google or Exchange Web Services calendar. You can also add local calendars through which you can add custom events. These calendars can then be linked to Time Conditions, Paging Pro groups, Find Me/Follow Me enabled/disable events and more!

To learn more about the new Calendar Module see: and

Remote calendars can be updated on a specific schedule you define. This allows you, the administrator, to delegate a calendar out to your users that they could update, adding events when the office is open which will then trigger Time Conditions at the appropriate times. We hope this new feature helps to ease configuration and management of your FreePBX systems.

A Redesigned UCP (User Control Panel)

Starting with the addition of the ARI back in the 2.x era, FreePBX has long had a need for a User Control Panel. A place where your end users can go to change specific settings related to their accounts or listen to voicemails or call recordings.

In FreePBX 12 we completely overhauled the UCP interface to give it important HTML5 updates. Including in-browser playback of recordings, notifications, a responsive interface, native chat and an in browser WebRTC phone. In FreePBX 14 we’ve gone one step further by giving your users complete control over how their Control Panel looks and feels.

With the additions of dashboards and widgets users can add, remove, resize and organize how they want their dashboard(s) in UCP to look and function. Users can have multiple dashboards that have different configurations of widgets. You could have one dashboard for your voicemail boxes and another dashboard that has widgets for your queues. For more information on the new UCP and what’s changed click here.

XMPP Improvements

Six months ago, we decided to open source our XMPP chat module but promised to continue improving the underlying source code.

Staying true to this promise we have completely reworked the internals of our XMPP module. Our new chat engine is more robust than ever and is fully supported by our flagship UC Zulu product line. Support for group chats, avatars, message history and more is already supplied in XMPP and best of all it’s free!

Zulu already supports these outstanding features and in the next few months the UCP chat interface will also support rooms, avatars and message history. We are very excited with how Zulu has progressed and how it’s also helped to expand the FreePBX Open Source Portfolio.

Moving Forward

In the next six months, we hope to release a Beta of FreePBX 15 with a redesigned backup module that will no longer be required to restore from the same version you are backing up to. This will also start our quicker release period where major FreePBX releases will happen every 6 months.

Get FreePBX 14 RC1 Today

Choose one of the following methods to install, provide feedback & report bugs:

Thank you for using FreePBX!