Install FreePBX and Asterisk on Ubuntu 24.04 LTS for security patches until 2036

Deploying FreePBX and Asterisk on a single Ubuntu virtual machine in a public cloud is an ideal solution for personal users and small to medium-sized businesses with voice over IP (VoIP) and fax over IP (FoIP) needs. This setup costs nothing, is scalable and secure, and has daily recovery points with a recovery time measured in minutes. In this article and its companion how-to guide on GitHub, you’ll go through the Day 0 to Day 2 process of provisioning a long-running FreePBX system that is reliable, easy to maintain, and optimized for both voice and fax communications.

While most VoIP providers can handle voice calls effectively, faxing over IP requires special care. Fax transmissions are especially sensitive to packet loss and variable latency (jitter), which can lead to failed faxes or poor-quality transmissions. For reliable faxing, it’s critical to use a provider that officially supports T.38 FoIP, an International Telecommunication Union (ITU-T) standard for sending faxes over IP networks in real-time which has a proven track record of compatibility with a wide range of fax machines and software. T38Fax Incorporated, for example, is a provider specifically designed to address these challenges, ensuring reliable faxing over SIP for all T.38 capable endpoints. Engineers at T38Fax are familiar with FreePBX and Asterisk installations on Ubuntu, and know how to configure and diagnose FoIP pass-through to fax server software, like HylaFAX Enterprise and OpenText RightFax, and analog telephone adapters (ATAs) connected to fax machines.

The evolution of Asterisk and FreePBX

Mark Spencer created the Asterisk software for Linux in 1999, and it significantly slashed the monthly telephone bills for homes and businesses. Homes and businesses originally connected to the public switched telephone network (PSTN) through analog voice lines maintained by regional telecom companies. Asterisk enabled homes and businesses to connect to the PSTN over the internet. VoIP benefited from lower overall transmission costs, each call did not require a dedicated line, and VoIP was initially exempt from all regulatory taxes.

Ward Mundy’s “asterisk@home” web frontend simplified Asterisk management, and was later rebranded as the Asterisk Management Project (AMP), and included FreePBX. Innovations by pioneers like Jeff Pulver were built on open source and proprietary VoIP innovations in the early 2000s, and this collective interest among technologists and consumers sparked a “cut-the-cord” movement. VoIP service market share grew from 4.7% in 1999 to 27% in 2008, according to the FCC’s 2010 “Trends in Telephone Service” report. Many telecom and hardware companies had to evolve, and began offering services and products that catered to Asterisk and FreePBX users.

Why faxing over IP is different

Faxing over IP is not the same as voice over IP. Fax machines are extremely sensitive to network conditions that impact audio quality. Voice calls can tolerate a higher degree of packet loss and latency, but fax transmissions require error-free delivery. The T.38 protocol is designed to compensate for imperfect networks, such as the internet, and improves the reliability of fax transmissions when using VoIP infrastructure.

While the science of T.38 may be sound, and it offers a compelling solution to the challenges presented by packet loss and jitter often experienced in real-world deployments over both public and private networks, the implementation of this technology in many carrier networks has been haphazard at best. It’s no surprise to us that many customers have struggled to achieve reliable fax transmissions using T.38

– Darren Nickerson, President of T38Fax

Indeed, not all VoIP providers support T.38, and even among those that do, reliability and compatibility varies wildly. Many providers recommend disabling error correction and/or reducing transmission speeds, or shut these features off at their media gateways. These workarounds mask problems around FoIP reliability, and result in faxes reported as successfully transmitted that are nonetheless illegible to the recipient. Even a properly configured FreePBX system cannot overcome misconfigurations at the provider level. Choosing a provider which specializes in T.38 FoIP ensures compatibility with a wide range of fax machines and software.

Key considerations when deploying FreePBX and Asterisk on Ubuntu

Five areas of focus are at top of mind when provisioning compute and network resources, and installing FreePBX and Asterisk:

1. Cost-effectiveness: The server deployment must be cheap to deploy and run over time, and the instance should be long-lived. Cost savings and minimal maintenance efforts are strong motivations.
2. Reliability and performance: Uptime is paramount, the network and the server must both be stable, reliable, and performant.
3. Infrastructure as Code (IaC): Installations of Asterisk and FreePBX should use version controlled, declarative, and idempotent instructions, limiting arbitrary commands and command injection risks, reducing privilege escalation risks, and implementing validation and error handling.
4. Predictable upgrades: Software upgrades, especially security and bugfixes, must not break existing configurations. Security patching automations should be enabled for automatic updates at appropriate intervals.
5. Recovery point objective (RPO) and recovery time objective (RTO): A daily RPO schedule with an RTO measured in minutes: in the event of a failure, the maximum acceptable data loss (RPO) is one day, and the maximum acceptable downtime (RTO) is only a few minutes. This can be achieved using a combination of the FreePBX Backup and Restore Module, and external storage such as an S3 bucket.

Day 0 to Day 2 operations

Bringing up a fully operational FreePBX system requires 3 phases. This article provides a guided journey, answering the “what” and “why” behind the implementation choices in the companion how-to guide on GitHub.

Day 0: Planning

Why Ubuntu? Installing FreePBX 17 and Asterisk 20.6 on Ubuntu 24.04 LTS allows you to benefit from Canonical’s security patching and systems management tools until April 2036, without having to contend with configuration changes associated with major version upgrades.

Why public clouds? Deploying to a public cloud provider with an “Always Free” service tier, is cost-effective, because there is no up front or recurring monthly cost when used within the always free limits. Both clouds provide robust networking for reliable operation and S3 compatible cloud storage for easy backup and recovery within their always free tier.

Both Google Cloud and Oracle Cloud provide a $300 credit. Google’s credit is valid for the first 90 days of every new account, and Oracle’s credit is valid for the first 30 days of every new account. These credits provide a buffer for any unanticipated usage beyond the always free tier.

• Why Google Cloud? Google Cloud provides 1 GB of outbound data transfer per month, from North America to all region destinations (excluding China and Australia) per month. E-mail delivery services for notifications have to be configured through SendGrid, Mailjet, or other external SMTP service provider. It is possible to sign up for a SendGrid account through Google Cloud which allows sending 12,000 free emails per month. Deploy FreePBX and Asterisk to an Ubuntu virtual machine on Google Cloud’s Always Free Tier using the gcloud utility.
• Why Oracle Cloud? Oracle Cloud provides virtual machines in the free tier worldwide, and allows 10 TB of outbound data transfer globally, each month. E-mail delivery service is included within the free tier, capped at 100 emails per day, but any external SMTP mail service provider can also be used. Install and configure FreePBX and Asterisk by manually triggering cloud-init modules on an already provisioned Ubuntu virtual machine in Oracle Cloud. It is also possible to deploy and provision FreePBX on an Ubuntu virtual machine using a preconfigured cloud-init.yaml file, through the Oracle Cloud’s web portal. Step by step instructions to use Oracle’s OCI command line utility to provision and deploy FreePBX have not yet been authored, and this could be an excellent Pull Request opportunity for any motivated open source contributors.

Day 1: Deployment

• Infrastructure as Code (IaC) ensures repeatable, secure, and idempotent installations. The companion how-to guide on GitHub provides a cloud-init YAML configuration file to deploy FreePBX on Ubuntu 24.04 LTS.
• Configure connections from commonly used VoIP and FoIP providers. Telnyx, Flowroute, BulkVS, and T38Fax cater to customers of various sizes, expertise, and budget. Their services are commonly discussed and reviewed on VoIP-specific forums and blogs. Flowroute and Telnyx provide service for international long-distance calls, and Telnyx can also provision phone numbers for incoming calls internationally. BulkVS and T38Fax do not provide outbound termination for international long-distance calls, and only terminate calls in North America. Rather uniquely, T38Fax is the only provider which does not provide VoIP service. By virtue of being optimized for faxing exclusively, they provide no guarantees that voice calls will connect successfully and only permit FoIP traffic on their network.

Day 2: Operations

• Validate T.38 configurations: While most VoIP configurations can be validated by monitoring the Asterisk service in the Asterisk CLI, FoIP configurations require deeper analysis to verify. Fax machines communicate over the T.30 protocol, which ideally gets encapsulated into a T.38 data stream, or is transmitted as voice traffic using an audio codec. Asterisk CLI will confirm if faxes are being transmitted via an audio codec or via a T.38 data stream. The presence or absence of T.30’s Error Correction Mode (ECM), like most fax session parameters,  is notoriously difficult to identify natively in Asterisk. Wireshark, a packet capture and analysis tool, can expose attributes of T.38 transmissions, including T.30 ECM error correction. For users who don’t want to go through the steps of analyzing a packet capture, T38Fax has published a free “Got ECM” online testing tool that can check your fax line, and verify if T.38 is configured to support ECM.
• Ubuntu Pro entitlements for security patching should be enabled. Enable the “esm-infra” entitlement to get security updates for all open source software published in Ubuntu’s “universe” repository, and enable the “esm-main” entitlement to get security updates for the Ubuntu LTS operating system beyond the 5 year standard support window. Ubuntu Pro also includes the Livepatch security patching automation tool to secure the Linux kernel on running systems, without causing downtime.

Day 0: Goals and requirements for your FreePBX system

Why should I install FreePBX on Ubuntu?

When installing FreePBX on Ubuntu 24.04 LTS, it is possible to perform the installation without compiling anything from source. Installing the majority of FreePBX’s software dependencies (like NodeJS, PHP, Asterisk, and Asterisk’s dependencies from Canonical’s official Ubuntu repositories) is a significant departure from every other FreePBX and Asterisk installation guide on the Internet today. This approach results in a FreePBX installation which benefits from Canonical’s security patching automations and systems management tools until April 2036.

Why deploy FreePBX to a single Ubuntu virtual machine?

For individuals and smaller organizations, installing and configuring FreePBX on a single Ubuntu virtual machine is simpler and far more cost-effective than configuring a high-availability cluster with Kamailio or OpenSIPS in front of multiple Asterisk servers. While such solutions exist for enterprises handling thousands of concurrent calls, they are beyond the scope of this article. Instead, this article will focus on:

• Ease of deployment, maintenance, and recovery
• Longevity of the deployment
• Total cost of ownership

Why should I deploy my Ubuntu virtual machine on a public cloud?

The ability to provision exactly the right amount of compute for your FreePBX server, with a streamlined path for upgrading its size, makes any public cloud an excellent deployment target for FreePBX. A virtual machine in a public cloud bypasses the inefficiencies associated with over-allocating resources on a physical server. Installing Ubuntu on bare metal instead of in a cloud VM also introduces issues around single points of failure in the entire stack, extending from the network to within the physical server. Generally, the network connectivity and the networking and server hardware in a public cloud datacenter are typically more robust than on-premise alternatives. Furthermore, virtual machines on all public clouds have snapshot capabilities, and often include preconfigured access to S3-compatible object storage. Google provides 5GB per month of free object storage, and Oracle provides 20GB total free object storage, which can be used for FreePBX backups. Both the VM snapshot and object storage features simplify backup, recovery, and rollback strategies.

Ubuntu equally supports a diverse range of CPU architectures, and FreePBX can be installed on any of them. Google Cloud provides Ubuntu images for both AMD64 and Arm64 architectures at various hardware configuration price points. Oracle includes generously sized Arm64 virtual machines in its always free tier, but they are difficult to reserve due to strong demand.

The Always Free tier of Google Cloud Compute Engine includes one e2-micro Ubuntu virtual machine in either the us-west1, us-central1, or us-east1 United States region, with the following configuration and limits:

• One 30GB hard disk and 1 GB RAM
• Two shared Intel Broadwell x86/64 cores
• One IPv4 and IPv6 address on their premium tier network, with a configurable cloud firewall
• Unlimited ingress (inbound to the VM) data transfer
• 1 GB of egress data transfer (outbound from the VMs) to anywhere in the world, except China and Australia

The Always Free tier of Oracle Cloud Infrastructure’s Compute includes two VM.Standard.E2.1.Micro Ubuntu virtual machines in any global Oracle region, with the following configuration and limits:

• One 50GB hard disk (up to a maximum of 200GB across all free instances) and 1 GB RAM
• One dedicated AMD EPYC 7551 32-Core Processor core, the machine is not oversubscribed
• Two IPv4 and IPv6 addresses, with a configurable cloud firewall
• 0.48 Gbps maximum throughput speed
• 10 TB of egress data transfer (outbound from the VMs) to anywhere in the world

How do I know if the Google or Oracle free tier VM is sufficient for my needs?

The load average in the FreePBX dashboard shows the average number of processes that are either running or waiting to run on the system in 1-minute, 5-minute, and 15-minute intervals.

When load averages exceed the number of vCPUs, a load of 2 for Google’s e2-micro instance, it is defined as a period of CPU bursting. CPU bursting means the instance is temporarily utilizing more of the physical core’s processing power to handle the increased demand. Google allows CPU bursting for up to 30 seconds before throttling the CPU. CPU bursting may be seen during server maintenance windows, but sustained bursting caused by FreePBX and Asterisk indicates your workload has outgrown the e2-micro machine. Virtual machines can be upgraded in place from e2-micro up to either the e2-small or e2-medium size VMs. Each step up doubles the bursting capacity: e2-small can use 100% of both allocated vCPU for 60 seconds at a time, and the e2-medium can sustain these spikes for 120 seconds, before CPU throttling is imposed. In other words, an e2-small can have a sustained load of 2 for 1 minute without slowing down, and an e2-medium can have a sustained load of 2 for 2 minutes without slowing down.

When load averages consistently exceed 1 on Oracle’s VM.Standard.E2.1.Micro instance, it is time to upgrade. Oracle’s free tier VMs are regular VMs, and not classified as burstable VMs. VMs have dedicated cores, and they are not oversubscribed. Consequently, bursting beyond the allocation is not possible.

Beyond monitoring CPU bursting from within the FreePBX dashboard, Google’s web portal at console.cloud.google.com provides recommendations when an e2-micro instance regularly has degraded CPU performance due to excessive bursting. Google will recommend an in-place upgrade of the virtual machine to a larger size, if it is deemed to be required. Performing an in-place upgrade entails shutting the machine down, changing the machine type from e2-micro to e2-medium or larger, and starting it up again. Oracle provides a comparable experience with Live Migration capabilities at cloud.oracle.com/compute/instances. Both public cloud providers offer the ability to reconfigure hardware when more resources are needed.

Network considerations for FreePBX SIP Trunks and Extensions

IPv4 and IPv6

Asterisk and the SIP and T.38 protocols have first class support for IPv6. While T.38 can work over IPv6, the vast majority of T.38 implementations are heavily reliant on IPv4. The practical reality of the existing infrastructure (and major service providers) operating largely on IPv4 exclusively, means that the public cloud Ubuntu virtual machine cannot be connected via IPv6 exclusively – the VM must also have an IPv4 address. IPv4 comes with its own challenges: traversing a router’s network address translation (NAT) can be complicated, and misconfigurations could result in one-way audio, no audio, or dropped calls.

NAT

Most virtual machines on public clouds have a 1-to-1 static NAT, so the VM’s external IP is static and their port internally is always the same as the external port. The FreePBX external IP address is under Settings > Asterisk SIP Settings > NAT  Settings  > External Address, and this is auto-configured by default during the initial FreePBX installation. VoIP and FoIP SIP trunk providers also advertise their correct IP address and port, so the connection between a cloud-hosted FreePBX server and a SIP trunk provider is straightforward.

 NAT-related complexity typically arises with SIP endpoints such as ATAs and softphones, registered to FreePBX Extensions. Small and medium-sized business (SMB) and small office home office (SoHo) routers and firewalls such as OpnSense, pfSense, Cisco Meraki, Ubiquiti UniFi, and mainstream mesh routers will often randomize the port number used on the external side of the NAT, and also only allocate the NAT mapping ephemerally. For UDP traffic this allocation is usually in the range of 30-300 seconds. Manufacturers further must employ one of several NAT security restrictions, usually (but not exclusively) grouped into: Symmetric NAT, Restricted Cone NAT,  Port Restricted Cone NAT, or Full Cone NAT.

There are a number of NAT traversal technologies hostable by cloud providers to assist in reaching an endpoint behind NAT: Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), Interactive Connectivity Establishment (ICE), and others. Of these, STUN is relatively common to encounter as some endpoints will have a STUN server configured by default, but it cannot assist in traversing highly restrictive NATs such as Symmetric NAT. 

Routers may also support various features to help endpoint devices in traversing their NAT, though these have limitations as well. Firewalls often have a SIP ALG (Application Layer Gateway) enabled by default that tries to modify SIP traffic to better traverse their NAT. In concept SIP ALGs sound useful, but vary widely in their coverage of the entire SIP protocol and sometimes need to be bypassed or completely disabled.  Protocols such as UPnP, PCP, and NAT-PMP that allows endpoints devices to communicate with their router to discover the endpoint’s own NAT mappings. However, due to security concerns, these protocols are often disabled in these deployments by users, administrators, or manufacturers that prioritize network security over convenience — and are not widely used in the VoIP industry. 

The variety, and also the compounding of these security restrictions create challenges for VoIP and FoIP devices and software. For example, highly secure OPNSense and pfSense deployments are more likely to have Symmetric NAT with UPnP-type services disabled by default. While secure, this also meant that VoIP implementers had to make extensive changes to a site’s firewall to get VoIP traffic flowing properly.

In response to these difficulties, over the years the Asterisk team has developed several NAT traversal strategies within Asterisk’s VoIP protocol implementations: even addressing certain problems that pose difficulties for third party solutions to address fully. FreePBX enables most of these by default. The SIP protocol and media streams flow over separate IPs and ports, so configurations for each must be applied separately.

NAT traversal mechanisms for SIP traffic:

• Rewrite Contact
  Default: On (Recommended)
  The SIP contact is recorded when an endpoint registers to an extension. This is the address to which you send new requests (like SIP INVITEs to start a call). It records the IP/port the registration came from, not the one that the endpoint (which might not know it’s behind a NAT) advertises.
• Force rport
  Default: On (Recommended)
  Very similar to Rewrite Contact, but helping with responses. Requests come with routing headers to indicate the path a response should take. The rport tag on these headers tells middleware that the IP/port on which the request was received should take precedence over the IP/port recorded in the SIP message. This setting tells FreePBX to follow this behavior even when the endpoint doesn’t supply the rport tag.
• Qualify Frequency:
  Default: 60 (Use: 25)
  Determines how often Asterisk will send out a SIP OPTIONS keepalive packet to keep a NAT session active. If the NAT mapping expires due to inactivity, the endpoint will be unreachable until it sends out new traffic, and even then it will probably pull a new port. The default setting for this is 60, but since some firewalls can time out their NAT mappings for UDP ports in only 30 seconds, 25 seconds may work better in some deployments.

NAT traversal mechanisms for the media streams:

• Direct Media
  Default: Off (Recommended)
  Disabling this setting puts Asterisk in the middle of all media streams. This is necessary for your PBX to assist in NAT traversal, otherwise you will have to rely on the NAT traversal policies of your carrier(s). Note that Asterisk always proxies T.38 traffic, regardless of this setting.
• RTP Symmetric
  Default: On (Recommended)
  Enabling symmetric RTP instructs Asterisk to send RTP traffic back to the IP/port you receive media from. Symmetric RTP only works if Direct Media is off.

Lastly, a site’s firewall may have SIP ALG enabled, which may interfere with your VoIP calls. You can avoid some SIP ALGs by changing the port on one or both sides of the connection from using the default UDP port 5060 or using TLS to encrypt the SIP traffic between your PBX and the endpoint. Other situations will require you to disable SIP ALG in the firewall.

Day 1: Deploy, install, and configure FreePBX, Asterisk, and Ubuntu

Infrastructure as Code

It is possible to deploy FreePBX 17 and Asterisk 20.6 on Ubuntu 24.04 LTS using modern Infrastructure as Code (IaC) best practices, using a single version controlled, declarative, and idempotent cloud-init YAML configuration file. This customizable cloud-init.yaml file deploys FreePBX 17 and Asterisk 20.6 on Ubuntu 24.04 LTS. This cloud-init.yaml file includes the bare minimum software required for a fully functional FreePBX and Asterisk installation. This lean initial installation can be expanded to include additional FreePBX modules, which can be installed from within the Module Admin section of the FreePBX web portal. Alternatively, the cloud-init configuration can be updated to install additional FreePBX Modules during the provisioning step, by adding the desired module names to Line 250 of the cloud-init.yaml file.

Public cloud providers support virtual machine creation through their web portal, and through command line applications. cloud-init YAML configuration files can be used in the web portals and command line utilities of every major public cloud. Version-controlling cloud-init.yaml configuration files can help keep them organized. Updating Line 42 to point to your own FreePBX backup results in a nearly instant restore-from-backup solution to create clones of a FreePBX machine, which can be useful in the context of disaster recovery.

Installing FreePBX and Asterisk with cloud-init ensures the installation and configuration is event driven, and the installation does not fail due to race conditions. There is guaranteed idempotence when using cloud-init’s modules, and cloud-init’s declarative configurations provide an improved security posture over shell scripts that are downloaded from the Internet and run as root.

Configuring connections

This “configuring connections” section assumes:

• successful completion of the installation of FreePBX on Ubuntu 24.04 LTS, as per the how-to guide published at https://github.com/rajannpatel/ubuntupbx, and access to the FreePBX web portal
• or, deep familiarity with FreePBX configurations and settings.

Connectivity > Trunks

As a convenience, the cloud-init.yaml file contains a link to a FreePBX Core Module backup, which contains Trunk and Outbound Routes configurations for several VoIP and FoIP SIP trunk providers. Enabling these trunks will require setting the boolean value for each desired SIP trunk provider in cloud-init.yaml to true, between Lines 45 and 48.

If you are using Flowroute, edit the Flowroute trunk, and under the “Dialed Number Manipulation Rules” tab, set the value for the Outbound Dial Prefix to match the Tech Prefix with an asterisk appended at the end. The Tech Prefix is a nine-digit numerical string which can be found in the Account Profile section of the Flowroute web portal. The value of the Outbound Dial Prefix will be in XXXXXXXXX* format. For example, if your Tech Prefix is “123412345” then the Outbound Dial Prefix should be: 123412345*

If you are using Telnyx, edit the Telnyx trunk, and under the “Dialed Number Manipulation Rules” tab, the value for the Outbound Dial Prefix must be the Tech Prefix from the Telnyx web portal. Within the Telnyx web portal, navigate to Voice > SIP Trunking, and Create SIP Connection. The option to specify a Tech Prefix is only available when using IP Address authentication.

No changes need to be made for the BulkVS and T38Fax trunks in FreePBX, they work out of the box. Log into customer portals at T38Fax and BulkVS and provide your IP address, so that incoming and outgoing calls can work. In the BulkVS customer portal, configure a BulkVS Trunk Group with incoming calls using “11 digits” delivery. Incoming calls formatted with E164 or 10 digits will not work with the default configurations in FreePBX.

Using 400 for the T38FaxMaxDatagram value

Under the T38Fax Trunk’s pjsip Settings > Advanced tab, T.38 has been enabled for FoIP. A conservative T38FaxMaxDatagram value of 400 has been set for this SIP trunk. While increasing this value provides limited to no additional value, it is interesting to understand what the maximum value could be. The T38FaxMaxDatagram parameter defines the maximum size of the data packets sent between fax endpoints and FoIP SIP trunks. Over the years, this value has been interpreted differently by different vendors.

Virtual machines in Google Cloud have a default MTU of 1460 bytes, and while the MTU is configurable on Google Cloud to be any value between 1300 bytes and 8896 bytes, changing the MTU isn’t necessary. Assuming 20 bytes of IP overhead, 8 bytes of UDP overhead, and 40 bytes of T.38 overhead, an estimate of 68 bytes for overhead is reasonable. The payload space is 1460 (MTU) – 68 (Overhead) = 1392 bytes. Setting T38FaxMaxDatagram to 400 is generously below the upper limit of 1392 bytes, when counting backwards from the default MTU of 1460 bytes. The preconfigured T38FaxMaxDatagram value of 400 is an excellent value for guaranteed operation with the widest range of T.38 capable hardware, in almost any network.

N11 Trunks

There are several preconfigured Custom Trunks for 211, 311, 411, 511, 711, 811, 988, and 911/922/933 with custom dial strings. The custom dial strings map the three-digit phone numbers (also known as service codes or N11 codes) to their 10-digit North American phone numbers. Many services like 211, 311, 511, and 811 vary by locality. An example would be the 311 service, which must route to +1 704 638-5246 in Salisbury, NC, but to +1 704 336-7600 in Charlotte, NC. Create a trunk for each service code to map the service code with its appropriate regional service phone number.

Ensuring the extensions reach their correct regional service phone number, when dialing the three-digit service code, is addressed in the Outbound Routes configuration. N11 Outbound Routes, especially 911 emergency services, should use SIP trunks intended for voice traffic, and not over a FoIP only SIP trunk, such as the one provided by T38Fax.

Outbound Routes Settings

Each Outbound Route in FreePBX can be configured to match a specific Trunk. The Outbound Routes are evaluated in top-down order. Outbound Routes can be selected based on Caller ID, or by prepending a unique dial string which matches a particular Outbound Route. 

“Caller ID” match patterns in Outbound Routes will be evaluated against the FreePBX Extension Number, and not necessarily the fax extension number’s configured outbound caller ID value. “X” matches any digit from 0-9, “Z” matches any digit from 1-9, and “N” matches any digit from 2-9. Setting the “Caller ID” match pattern in the “t38fax” Outbound Route to “999Z” will match any FreePBX Extension numbered between 9991 and 9999. This allows fax extensions to make outbound calls using the T38Fax trunk exclusively, and voice traffic is routed through voice carriers.

Extension and Ring Groups Settings

Navigating to Connectivity > Extensions and clicking the Add Extension > Add New SIP [chan_pjsip] Extension button creates a SIP account in FreePBX, where the extension number is the username. It is possible to connect ATAs or softphones to Extensions.

Configurations for faxing under the Extension’s “Advanced” tab

For fax machine extensions, under Advanced, edit the Direct Media setting to reflect “No”. If Direct Media is enabled, the RTP portion of the call bypasses Asterisk, but the T.38 re-INVITE forces the Asterisk server back into the middle of the UDPTL media stream. This additional complication provides no benefit.

Fax software like iFax’s HylaFax and T38FaxVoIP’s Fax VoIP FSP Windows Fax Service Provider support elastic SIP trunks. An elastic SIP trunk can support multiple concurrent calls on a single SIP registration. In FreePBX, under the Extension’s “Advanced” tab, the Outbound Concurrency Limit is set to 3 by default. That number can be raised to reflect however many simultaneous outbound faxes that extension needs to be able to send.

While Asterisk by default suppresses Call Waiting tones when a T.38 fax session is active, disabling the Call Waiting feature entirely from within the Advanced tab is a prudent choice.

Applications > Ring Groups

For fax softphones and fax server software that support multiple SIP registrations, create a unique extension for however many concurrent incoming fax streams the system needs to support. If the maximum number of concurrent incoming faxes is 8, create 8 extensions. All the extensions can be added to a Ring Group, set the “Ring Strategy” drop down selection to “firstavailable”. The “Destination if no answer” setting should be Terminate Call > Busy. Fax machines will reattempt sending a fax at a later time by default, if they receive a busy signal.

Connectivity > Inbound Routes

When adding Inbound Routes, the DID Number should always be 11 digits, assuming a North American phone number is being used. Specify the country code “1”, followed by the 10-digit phone number (for example: 17182222222)

Admin > Backup & Restore

Adding a regularly scheduled backup of all FreePBX Modules except the Framework Module is advisable. The backup without the Framework Module is useful for migrating to newer installations of FreePBX. Adding a regularly scheduled backup of all FreePBX Modules, including the Framework Module, is useful for disaster recovery, when the target system is running the same major FreePBX version.

The Storage Location is set to “_ASTSPOOLDIR_/backup”, which resolves to “/var/spool/asterisk/backup” on Ubuntu. The “backup” folder has been created in that spool directory at installation time, via cloud-init. The Delete After Runs setting is set to 1, and Delete After Days is set to Unlimited. Given these constraints, only 1 backup will be kept at any given moment.

FreePBX only natively connects with AWS S3 Buckets. However, virtual machines running on Google Cloud have the gcloud utility preinstalled, and they can access S3 Buckets on Google Cloud within the same project. It is possible to copy the contents of /var/spool/asterisk/backup on a daily basis to an S3 bucket in Google Cloud, and use the S3 bucket’s object lifecycle management rules to retire backups older than a certain age, automatically.

Copying the latest backup(s) can be achieved by running `crontab -e` and adding this line to the crontab:

@daily gcloud storage rsync /var/spool/asterisk/backup gs://example-s3-bucket/backup --recursive

Due to a bug in the Backup & Restore FreePBX Module version 17.0.5.62, restoring the Backup & Restore Module configurations from a backup does not restore the crontab entries for the “asterisk” user. Any scheduled, recurring backups would have to be edited and re-saved within the FreePBX portal to generate the appropriate crontab entries for the “asterisk” user.

To deploy a new Ubuntu virtual machine in Google Cloud and restore a backup from your Google Cloud Storage S3 bucket, edit the cloud-init.yaml file and change line 43:

{% set RESTORE_BACKUP = 'https://github.com/rajannpatel/ubuntupbx/raw/refs/heads/main/ubuntupbx.core.backup.tar.gz' %}

Instead of downloading the ubuntupbx.core.backup.tar.gz from GitHub, provide the address of your backup file in Google Cloud Storage. Remember to double-check the external IP address configuration on the target system when restoring from a backup, incorrect external IP address configurations will cause no audio issues on extensions and trunks. The FreePBX external IP address is set under Settings > Asterisk SIP Settings > NAT  Settings  > External Address.

Day 2: Maintain operational status and security

Validate optimal T.38 configurations

Got ECM?

T38Fax provides a free “Got ECM” fax-back testing tool that can check your incoming and outgoing faxes to verify if your fax connection has T.30 ECM enabled. Submit the form with your email address and fax number. The “Got ECM” service will email you a copy of a 1 page fax that is sent to your fax endpoint, confirm if T.30 ECM was enabled, and provide other useful information including: Quality (as a scalar value), Page Width, Page Length, Signal Rate, Data Format, and the total number of attempts required to complete the test.

This information can also be validated with packet captures.

Fax over IP Protocol Inspection

Packet captures can be performed on the Ubuntu server running Asterisk. Performing packet captures here provides insight into what is happening with the SIP trunk to the carrier, and also provides insight into the communication between Asterisk and the fax machine. Alternatively, Wireshark can be used to inspect packet capture (PCAP) dumps on the network where the fax machine is running. Despite not having insights into the traffic between Asterisk and SIP Trunk, there is still enough data to validate the T.38 protocol is in use, and that the fax transmission is via UDPTL, and not via G711u encoded RTP packets. The PCAP can also be used to verify if error correction in fax transmissions is comprehensively enabled.

When T.38 is in use, reliable fax transmissions require inbound and outbound faxes to use network and application error correction features:

• T.38 UDP Redundancy Error Correction (UDP EC)
• T.38 Forward Error Correction (FEC)
• T.30 Error Correction Mode (ECM)

FEC and UDP redundancy function at the network layer, while ECM works at the application layer. Both FEC and UDP redundancy operate at the network layer and address the problem of packet loss during transmission, by sending duplicates of the data. ECM detects errors after transmission of each page, and requests block retransmission only for corrupted segments of that page before moving on to the next page. This is how ECM ensures the received fax image is identical to the one that was sent, thereby ensuring100% error-free delivery.

T.38 Error Correction

The T.38 re-INVITE step of a call ladder is the responsibility of the recipient of the fax. For outgoing calls, when fax tones are present carriers like T38Fax will re-INVITE the sender. For incoming calls, the T.38 endpoint receiving the call is responsible for sending the re-INVITE. This is the only way to avoid mid-air collisions where both sides re-INVITE simultaneously, a situation that can sometimes prevent T.38 negotiation, resulting in either a fallback to the G.711 audio codec, or a complete failure. The sender of the T.38 re-INVITE chooses between FEC and UDP redundancy for the entire T.38 session – and this error correction is used during handshake, training, and image transmission – but the de-facto standard today is UDP redundancy.

UDP redundancy is usually tuned with different values for high-speed (HS) and low-speed (LS) signaling. LS signaling is used for inter-page procedures such as handshake and training, that must make it across at all costs. HS signaling is used for image transmission, comprising the vast majority of the packets. When configurable, T38Fax recommends 5 for LS and 2 for HS when faxing over their ECM-enabled network. High redundancy for page data would be overkill with ECM correcting any page data errors at the end of page (EOP) procedures.

Every carrier mentioned in this article defaults to UDP redundancy, and none default to using FEC. The complexity FEC introduces does not justify its efficiency, especially if one leg of a transmission is using FEC and another leg of the transmission is using UDP redundancy. Morgan Scarafiotti from the Support Engineering team at T38Fax weighs in, “I think it’s worth contextualizing FEC vs redundancy with some back-of-the-napkin estimation. A standard G.711u or G.711a call consumes a guaranteed 64kbps on the payload alone. Even if you use 3x redundancy, so 4 total copies of the data, you’re looking at about 14,400bps*4 = ~57,600bps in the payload at max speed. Compared to a standard G.711codec you’re still saving a little bit of data even with quite a lot of redundancy. So, it’s true that FEC consumes even less bandwidth, maybe half of that, but redundancy doesn’t consume a whole lot of data to begin with.”

FEC sends extra data in subsequent packets that contain information derived from the previous data packets. The receiver can use these FEC packets to reconstruct lost or damaged data. FEC requires more encoding and decoding, but requires less network overhead than UDP redundancy. With UDP redundancy, retransmission of the IFP (Internet Facsimile Protocol) packets are included in subsequent IP packets destined to the fax recipient. The retransmitted data is verified against what was previously received. In theory, this implementation makes the fax transmission more resilient against failure from packet loss. In practice, it could quadruple the transmission overhead, and there are interop problems due to insufficient testing on the rare occasions it is used.

Network error correction features can be validated by filtering the PCAP by “sdp” to find the “Status: 200 OK (INVITE)” frame, and drilling into Session Initiation Protocol (200) > Message Body > Session Description Protocol in the packet details pane, and finding “a=T38FaxUdpEC:t38UDPRedundancy”

T.30 Error Correction

FoIP transmissions with ECM disabled may result in image artifacts, such as long black horizontal lines, or lines of text completely missing, leading to an arguably false-positive “successful transmission” confirmation when the fax call ends. Enabling ECM can extend the duration of fax transmissions by a small margin of a few seconds per page, because errors in the received image are addressed by retransmitting the original page data. VoIP SIP trunk providers may not offer T.38 support at all, but when T.38 is implemented, T.30 ECM is often missing.

When inspecting a packet capture with Wireshark, validating ECM requires filtering by “t30.fif.ecm”. This filter will reveal 2 frames, the “Digital Identification Signal (DIS)” and the “Digital Command Signal (DCS)” frames. In the DCS frame, drill into ITU-T Recommendation T.38 > UDPTLPacket > primary-ifp-packet > data-field > Item 0 > Data-Field > ITU-T Recommendation T.30 > Facsimile Control: Digital Command Signal. When “Error Correction Mode: Set”  has a 1 in the third bit, as shown in the highlighted screenshot below, it is proof that T.30 ECM is enabled.

Manual and automated patch management on Linux

Almost every other guide directs users to compile Asterisk from source. However, it is challenging to maintain Linux systems with packages compiled from source. When some packages are self-compiled, and others are installed from package managers, there is a heightened risk of dependency conflicts and version mismatches. A customized process is required to apply security updates in an application-specific manner; these nonstandard package installations represent snowflakes of management complexity in a Linux estate. Self-compiled software often relies on specific versions of libraries, and these versions might conflict with the versions required by packages installed through the system’s package manager. 

Resolving these conflicts can be a complex and time-consuming process. Packages installed through the system’s package manager are typically tracked and updated automatically.  When software is compiled from source, the user is responsible for tracking and applying security patches. This is a significant burden and increases the risk of running vulnerable software, especially when the path of least resistance is to avoid updating the self-compiled software.

Security patching all open source software installed on Ubuntu

Canonical has a 20-year track record of timely security updates for the main Ubuntu OS, with critical CVEs patched in less than 24 hours on average. Ubuntu Pro expands this coverage to include software installed from the universe repository. Patches are applied for critical, high, and selected medium CVEs, with many zero-day vulnerabilities fixed under embargo for release the moment the CVE is public.

Ubuntu Pro provides security coverage for almost 30,000 open source software titles, which include over 100,000 open source software packages. Asterisk and all its dependencies are included in the official Ubuntu repositories, and are covered with Ubuntu Pro. This open source software can be installed on Ubuntu with apt or apt-get. The major version of any software package installed from the official Ubuntu repositories is pinned for every Ubuntu LTS version, but the minor version number for each software package is incremented every time Canonical packages and publishes bugfixes and security updates for these major versions. These security patches may come from the upstream publisher of the open source software, or they may be contributed by Canonical to the upstream publisher.

Just like every Ubuntu LTS version, all packages installed via apt or apt-get from Canonical’s repositories or their mirrors also get 10 years of security patches when a free or paid Ubuntu Pro token is attached to the machine. If you do not launch a premium Ubuntu Pro image on public cloud, you can attach your Ubuntu Pro token on your Ubuntu 24.04 LTS machine by specifying it in cloud-init.yaml. When installing FreePBX on Ubuntu 24.04 LTS, the security patching benefits are realized immediately for every FreePBX dependency installed from Canonical’s Ubuntu repositories, or its mirrors. Ubuntu Pro enables the entitlement for both the “esm-apps” and “esm-infra” security repositories, at the time of this writing they already contain security patches for the following Asterisk dependencies:

• libcjson1
• libavdevice60
• ffmpeg
• libpostproc57
• libavcodec60
• libavutil58
• libswscale7
• libswresample4
• libavformat60
• libavfilter9

As Canonical publishes more security patches for additional vulnerabilities, as they are found, this list will continue to grow. On an Ubuntu 24.04 LTS instance without Ubuntu Pro, these security updates are not available:

ubuntu@pbx:~$ sudo apt update && sudo apt upgrade
Hit:1 http://us-east1.gce.archive.ubuntu.com/ubuntu noble InRelease
Hit:2 http://us-east1.gce.archive.ubuntu.com/ubuntu noble-updates InRelease                   
Hit:3 http://us-east1.gce.archive.ubuntu.com/ubuntu noble-backports InRelease                 
Hit:4 http://security.ubuntu.com/ubuntu noble-security InRelease                              
Hit:5 https://ppa.launchpadcontent.net/ondrej/php/ubuntu noble InRelease                      
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Get more security updates through Ubuntu Pro with 'esm-apps' enabled:
  libcjson1 libavdevice60 ffmpeg libpostproc57 libavcodec60 libavutil58
  libswscale7 libswresample4 libavformat60 libavfilter9
Learn more about Ubuntu Pro on GCP at https://ubuntu.com/gcp/pro
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
ubuntu@pbx:~$ 

Not all open source software maintainers will maintain their software for 10 years. For example, Sangoma security patches Asterisk LTS versions for four years. As an alternative to downloading the Asterisk tarball from Sangoma’s website and manually installing it on Ubuntu, performing apt install asterisk on Ubuntu 24.04 results in an installation of Asterisk version 20. Ubuntu 24.04 LTS will always only ever contain Asterisk version 20 in its “universe” repository. However, Asterisk version 20 in the Ubuntu 24.04 LTS universe repository gets in-place security patches for 10 years, despite going end-of-life after four years. How does Canonical provide six years of additional security patching beyond Sangoma’s four-year security patching window for Asterisk version 20? Well, it’s simple: Canonical backports security patches from Sangoma’s currently maintained version of Asterisk. Similarly, Canonical authors its own security patches for all open source software it packages and publishes in its repositories, beyond Asterisk. Even when upstream software maintainers have marked versions of software included in an Ubuntu LTS release as end-of-life, Canonical ensures that every version of Ubuntu LTS and the software made available for installation on it, is safe and stable for a decade.

Anybody running Ubuntu 24.04 LTS with an Ubuntu Pro subscription (free or paid) will get security updates for packages installed from Canonical repositories until April 2036. Even when the stewards of Asterisk, NodeJS, and other open source software you rely on have shifted focus to newer versions of their software, you can rely on Canonical to provide security updates for what you have deployed on Ubuntu 24.04 LTS until April 2036, and longer for customers to purchase the +2 year Legacy Support add-on to Ubuntu Pro, as the 10-year security coverage window for Ubuntu Pro comes close to elapsing.

Security patching automations for the Linux kernel

Livepatch shrinks the exploit window for critical and high severity Linux kernel vulnerabilities, by patching the Linux kernel between security maintenance windows. While updates to the kernel installed via apt or apt-get require a reboot to take effect, Livepatch security patches do not require a reboot. Livepatch security patches exist in memory, and are forgotten upon reboot. At startup, Livepatch reevaluates the kernel version and reapplies the appropriate live kernel patches. High and critical vulnerabilities need to be addressed immediately, but software like Asterisk introduces constraints around when security patching related reboots can occur. However, nobody wants their faxes or voice calls dropped midway due to impromptu security patching. To prevent such a scenario, Livepatch is an interim solution for patching high and critical severity security vulnerabilities in the kernel, in reboot-sensitive environments.

Livepatch requires an upgrade and reboot every 13 months when running general availability (GA) kernels, and every 9 months when running hardware enablement (HWE) kernels. Ubuntu Desktop and public cloud virtual machines run HWE kernels by default, whereas Ubuntu Server installs the GA kernel by default. Canonical does not perform testing on cumulative live kernel patches beyond 13- and 9-month windows respectively, for each kernel; consequently, there is no security patching available via Livepatch beyond that range.

Reconciling the desire to always have up-to-date security patches, and having the fewest predictable security patching upgrade and reboot intervals, results in a bi-annual security patching cadence. Upgrade and reboot the machine after Canonical has published the latest kernels, in the spring and fall. Enable Livepatch to provide protection against critical and high vulnerabilities in between those windows.

Livepatch is enabled by default when deploying FreePBX with the cloud-init file from the companion how-to guide in GitHub.

Since we first launched Ubuntu LTS, with five years’ free security coverage for the main OS, our enterprise customers have asked us to cover more and more of the wider open-source landscape under private commercial agreements. Today, we are excited to offer the benefits of all of that work, free of charge, to anyone in the world, with a free personal Ubuntu Pro subscription.

– Mark Shuttleworth, CEO of Canonical

Recommended security patching cadences for FreePBX and Asterisk on Ubuntu

It is prudent to differentiate between bugfix patches and security patches. FreePBX supports this distinction for their own modules under Admin > Module Admin > Scheduler and Alerts:

When setting Automatic Module Updates to Email Only, the onus is on the system administrator to remember to apply the non-security software updates manually. With Automatic Module Security Updates enabled, they will be applied between midnight and 4AM daily. Through cloud-init.yaml, the unattended-upgrades and needrestart packages have been configured to install security updates daily at 4:10 AM, with a reboot (if necessary) at 4:30 AM.

# TIME TO INSTALL AND REBOOT UBUNTU FOR SECURITY PATCHES FROM CANONICAL IN XX:XX FORMAT
{% set SECURITY_INSTALL_TIME = "04:10" %}
{% set SECURITY_REBOOT_TIME = "04:30" %}

To conform with the smallest risk appetite, apply security updates daily, with a nightly reboot.

To manually apply the regular non-security FreePBX Module updates, visit Admin > Module Admin > Module Updates within the FreePBX web portal, click the “Check Online” button, add or remove the modules that need updating, and click “Process” to manually trigger the update process.

Scheduled disk cleanup

It’s crucial to manage disk usage effectively on a long-running FreePBX deployment. Several factors can contribute to disk filling, including accumulating voicemails, call recordings (often used for training), verbose logging (common during configuration), and the growth of Call Detail Records (CDR) and Call Event Logging (CEL) databases.  These potential issues are mitigated by the following disk space management strategies implemented in the cloud-init.yaml file:

# NUMBER OF DAYS TO RETAIN CDR AND CEL RECORDS IN FREEPBX
{% set CDR_RETENTION_DAYS = "60" %}
{% set CEL_RETENTION_DAYS = "60" %}

These configurations ensure Call Detail Records and Call Event Logs are emptied every 60 days.

Additionally, cloud-init.yaml sets crontab entries to prune call recordings (if enabled) and voicemails older than 45 days. Logrotate is configured to rotate logs up to 3 times on a daily and weekly basis.

Linux systems management with Landscape

Landscape is a Linux systems management tool designed to help you manage, monitor, secure, and inventory all aspects of your Ubuntu instances from a unified platform. Landscape is included with Ubuntu Pro, even at the free tier. Landscape provides system administration and security patching capabilities for Ubuntu via a web portal and API.

Landscape uses a client-server architecture, where a central Landscape Server manages an Ubuntu fleet. Launch an interactive wizard to connect Landscape Client with Landscape Server with Pro Client on Ubuntu 24.04 LTS:

$ pro enable landscape

Final thoughts

Deploying FreePBX and Asterisk on Ubuntu, particularly within a public cloud environment, offers a robust, cost-effective, and scalable solution for personal users and small to medium-sized businesses.

We’re thrilled to see fax-specific configuration tips and best practices in a FreePBX deployment guide for Ubuntu. In a fast-moving, increasingly voice-centric industry Canonical has given its users powerful tools to build a long-lived platform that is optimized for reliable voice and fax transmissions, and we are pleased to recommend Ubuntu to our customers.

– Darren Nickerson, President of T38Fax

By leveraging modern Infrastructure as Code practices, automated security patching, and reliable disaster recovery strategies, this setup ensures long-term stability, security, and performance. The integration of Ubuntu Pro further enhances security by providing extended support for critical open source software dependencies, closing exploit windows between vulnerability detection and scheduled security patching intervals with Livepatch, and simplifying Linux systems management and monitoring with Landscape.

These deployment choices not only address the historical challenges of Asterisk and FreePBX maintenance, but also align with contemporary best practices for reliability, cost-efficiency, and security. Whether you’re managing a small office or scaling up for larger operations, this guide provides a comprehensive framework for deploying and maintaining a resilient FreePBX and Asterisk based VoIP and FoIP system in 2025.