VOIP & Unified Communications Hosting on Dedicated Servers

Why Dedicated Hardware vs Cloud for VOIP

VOIP quality is sensitive to network jitter and latency in ways that web applications are not. A 50ms spike in a web request adds 50ms to page load — noticeable but not catastrophic. A 50ms spike in an active phone call is audible as a click or dropout. A 200ms spike causes words to cut out entirely.

Cloud instances introduce two sources of jitter that dedicated servers eliminate: hypervisor scheduling variability (the VM waits for CPU time when the physical host is under load) and noisy-neighbor network congestion. Asterisk’s own documentation recommends dedicated hardware for production deployments specifically because of these factors.

A dedicated server with burstable 10Gbps connectivity as provided by InMotion Hosting’s dedicated server lineup provides the low-jitter, low-latency network environment that call quality requires. The Essential tier (64GB RAM, Intel-based processor) handles 500+ simultaneous SIP calls comfortably; the Extreme tier with AMD EPYC handles several thousand.

Asterisk and FreePBX: Understanding the Stack

Asterisk is the open source telephony engine. It handles call routing, SIP signaling, media processing, and integration with external providers. It’s configured via text files and requires significant technical knowledge to configure from scratch.

FreePBX is a web-based administration interface built on top of Asterisk. It provides a GUI for configuring extensions, IVR menus, call queues, voicemail, and SIP trunk connections without editing Asterisk configuration files directly. Most self-hosted VOIP deployments use FreePBX as the management layer over Asterisk.

Distros that bundle both:

• FreePBX Distro (CentOS-based, maintained by Sangoma)
• PBX in a Flash
• VoIP.ms’s recommended stack

For a fresh deployment on InMotion’s dedicated servers, the FreePBX Distro ISO is the fastest path to a working system — it installs Asterisk, FreePBX, and all dependencies in a single process.

Server Hardware Requirements

FreePBX’s hardware requirements scale with simultaneous call volume and codec choices:

Codec choice significantly affects CPU load. G.711 (ulaw/alaw) passes audio without transcoding — it’s raw PCM audio at 64Kbps per channel. G.729 is the compressed alternative at 8Kbps, requiring CPU transcoding on every call. At 100 simultaneous G.729 calls, transcoding alone consumes 2-4 CPU cores on a modern processor.

For most SMB deployments (under 200 simultaneous calls), InMotion’s Essential server ($99.99/month) provides substantial headroom. The 64GB RAM far exceeds VOIP requirements; the Intel processor handles the transcoding load comfortably with cores left over for other services.

FreePBX Installation on AlmaLinux

AlmaLinux 8 is the recommended OS for production FreePBX deployments as of 2025, following CentOS 8’s end-of-life.

# Update base system

dnf update -y

# Install dependencies

dnf install -y wget git

# Download and run FreePBX install script

wget https://github.com/FreePBX/sng_freepbx_debian_install/releases/download/latest/sangoma_freepbx_install.sh

# Review the script before executing

bash sangoma_freepbx_install.sh

# The script installs Asterisk, FreePBX, and web UI

# Access FreePBX admin at http://your-server-ip/admin

# Update base system

dnf update -y

# Install dependencies

dnf install -y wget git

# Download and run FreePBX install script

wget https://github.com/FreePBX/sng_freepbx_debian_install/releases/download/latest/sangoma_freepbx_install.sh

# Review the script before executing

bash sangoma_freepbx_install.sh

# The script installs Asterisk, FreePBX, and web UI

# Access FreePBX admin at http://your-server-ip/admin

After installation, the FreePBX admin UI handles the remaining configuration: setting the admin password, configuring SIP trunks, creating extensions, and building the IVR.

SIP Trunk Configuration

A SIP trunk connects your Asterisk server to the PSTN (Public Switched Telephone Network) — the regular phone network. Commercial SIP trunk providers bill per-minute or offer flat-rate channel plans.

Recommended SIP trunk providers for dedicated server deployments:

• Twilio Elastic SIP Trunking — per-minute pricing, no monthly minimums, excellent documentation
• VoIP.ms — Canadian provider with US termination, flat-rate and per-minute options
• Telnyx — competitive pricing with good developer documentation

In FreePBX, trunks are configured under Connectivity > Trunks. A typical SIP trunk configuration:

Trunk Name: Primary_SIP_Trunk

Outbound CallerID: Your DID number

PEER Details:

host=sip.provider.com

type=peer

qualify=yes

nat=force_rport,comedia

dtmfmode=rfc2833

context=from-trunk

Trunk Name: Primary_SIP_Trunk

Outbound CallerID: Your DID number

PEER Details:

host=sip.provider.com

type=peer

qualify=yes

nat=force_rport,comedia

dtmfmode=rfc2833

context=from-trunk

Network and Firewall Configuration for VOIP

VOIP requires specific firewall configuration. SIP signaling uses UDP/TCP port 5060; media (RTP audio) uses a range of UDP ports:

# SIP signaling

nft add rule inet filter input udp dport 5060 accept

nft add rule inet filter input tcp dport 5060 accept

# RTP media ports (FreePBX default range)

nft add rule inet filter input udp dport 10000-20000 accept

# FreePBX web interface (restrict to admin IPs)

nft add rule inet filter input ip saddr 203.0.113.0/32 tcp dport 80 accept

nft add rule inet filter input ip saddr 203.0.113.0/32 tcp dport 443 accept

# SIP signaling

nft add rule inet filter input udp dport 5060 accept

nft add rule inet filter input tcp dport 5060 accept

# RTP media ports (FreePBX default range)

nft add rule inet filter input udp dport 10000-20000 accept

# FreePBX web interface (restrict to admin IPs)

nft add rule inet filter input ip saddr 203.0.113.0/32 tcp dport 80 accept

nft add rule inet filter input ip saddr 203.0.113.0/32 tcp dport 443 accept

Fail2Ban is mandatory for VOIP servers. SIP port 5060 is scanned continuously by automated tools attempting to register extensions and make calls at your expense. Fail2Ban with the Asterisk jail blocks IPs after failed registration attempts:

# /etc/fail2ban/jail.local

[asterisk]

enabled = true

port = 5060

filter = asterisk

logpath = /var/log/asterisk/security

maxretry = 3

bantime = 3600

# /etc/fail2ban/jail.local

[asterisk]

enabled = true

port = 5060

filter = asterisk

logpath = /var/log/asterisk/security

maxretry = 3

bantime = 3600

Without Fail2Ban, a compromised extension credential results in thousands of dollars in fraudulent international calls within hours. This is not hypothetical — SIP toll fraud is one of the most common and costly incidents on improperly secured VOIP deployments.

Call Quality Optimization

QoS (Quality of Service) marking: Mark VOIP packets with DSCP EF (Expedited Forwarding) so network equipment prioritizes them over bulk data traffic:

# Mark outbound RTP packets with DSCP EF (46)

nft add rule inet mangle output ip protocol udp udp dport 10000-20000 ip dscp set ef

nft add rule inet mangle output ip protocol udp udp dport 5060 ip dscp set ef

# Mark outbound RTP packets with DSCP EF (46)

nft add rule inet mangle output ip protocol udp udp dport 10000-20000 ip dscp set ef

nft add rule inet mangle output ip protocol udp udp dport 5060 ip dscp set ef

Kernel timer resolution: VOIP timing is sensitive to kernel scheduling delays. On heavily loaded servers, set CONFIG_HZ=1000 in the kernel configuration to reduce scheduling latency. For most dedicated server configurations, the default is already appropriate; verify with grep CONFIG_HZ /boot/config-$(uname -r).

Disable swap for RTP buffers. Memory paging during active call processing introduces latency spikes. With InMotion’s Essential server at 64GB RAM running a modest VOIP deployment, swap should never be touched. Confirm with free -m and set vm.swappiness=1 in /etc/sysctl.conf as a preventive measure.

Monitoring Call Quality

Asterisk logs call data records (CDRs) that provide post-call quality metrics. The RTPAUDIOQOS variable in the CDR captures jitter, packet loss, and round-trip time per call. Monitor for:

• Jitter above 30ms: Audible audio quality degradation
• Packet loss above 1%: Dropped words, choppy audio
• Round-trip time above 150ms: Perceptible delay in conversation

Asterisk’s realtime CDR documentation covers storing CDR data in MySQL for analysis. For production deployments, storing CDR data allows trend analysis helps with identifying whether call quality problems correlate with time of day (server load), specific SIP trunks, or specific geographic routes.

InMotion’s Premier Care includes 24/7 support. For VOIP deployments where call quality problems could affect business operations, having access to expert support for server-level issues like network problems, resource contention, hardware anomalies is worth the additional cost.

Related reading: Server Hardening Best Practices | Network Latency Optimization for Dedicated Servers