How to run VICIdial on Azure

Azure is the most common cloud for organizations that already run Microsoft workloads, so it is natural to ask whether VICIdial can live there too. The short answer is yes. The longer answer involves Network Security Groups, Azure's outbound NAT behavior, and a few defaults that will cause one-way audio if you do not address them deliberately.

This guide covers what is Azure-specific. For the underlying VICIdial cloud-hosting concepts, start with running VICIdial in the cloud.

VM sizing for VICIdial

Azure's VM catalog is large. For VICIdial, the D-series general-purpose VMs are a sensible starting point. A D4s_v5 (4 vCPUs, 16 GB RAM) handles a small-to-medium dialing center running up to 30 concurrent calls (Concurrent calls, the number of active voice sessions at one time). The extra memory compared to a 4-vCPU/8 GB instance gives MySQL more buffer pool, which matters for VICIdial's continuous read/write pattern.

Avoid the B-series burstable VMs for production dialing. They accumulate CPU credits during idle periods and spend them under load, but VICIdial — especially with predictive dialing (Predictive dialing, the mode that dials ahead of available agents) — never idles. You will deplete the credit bank and throttle to baseline within minutes of your campaign starting.

Network Security Groups: SIP and RTP rules

Azure's Network Security Group (NSG) controls inbound and outbound traffic at the NIC and subnet level. By default, a new VM NSG blocks all inbound except SSH (port 22). You need to add inbound rules for SIP (SIP (Session Initiation Protocol), the protocol that sets up, modifies, and ends VoIP calls) and for the RTP media range (RTP, the real-time UDP stream carrying audio between Asterisk and your carrier or agents).

flowchart TD
    A[Carrier SIP packet] --> B{Azure NSG inbound}
    B -- rule: allow 5060 --> C[VM NIC]
    B -- no rule --> D[Dropped silently]
    C --> E[Asterisk SIP stack]
    E --> F{RTP audio}
    F -- rule: allow UDP 10000-20000 --> G[Two-way audio]
    F -- blocked --> H[One-way audio or silence]

# Azure NSG inbound rules (add via Portal or az CLI):
# Priority 200  Allow  UDP/TCP  5060         Any->Any  SIP
# Priority 210  Allow  UDP      10000-20000  Any->Any  RTP media
# Priority 300  Allow  TCP      443          Any->Any  HTTPS
# Priority 400  Allow  TCP      22           Admin/Any SSH

# az CLI example for RTP:
az network nsg rule create \
  --resource-group myRG \
  --nsg-name myNSG \
  --name AllowRTP \
  --priority 210 \
  --protocol Udp \
  --direction Inbound \
  --source-address-prefixes '*' \
  --source-port-ranges '*' \
  --destination-port-ranges 10000-20000 \
  --access Allow

Azure NAT and public IP behavior

Azure VMs sit behind a platform-managed outbound NAT by default when attached to a standard load balancer or using the default outbound access mechanism. For a standalone VM with a public IP attached directly to the NIC, traffic flows without SNAT for both inbound and outbound — which is what you want. Assign a static public IP (not dynamic) to the NIC before provisioning; dynamic IPs can change on deallocation.

In your Asterisk configuration set externip to the static public IP and localnet to the Azure VNet prefix. NAT traversal (NAT traversal, the Asterisk mechanism that rewrites SDP contact addresses to the public-facing IP) should be enabled in this configuration even though Azure does not itself NAT, because Asterisk will otherwise advertise the private VNet address in SDP and your carrier will be unable to send RTP back to you.

Storage for recordings and snapshots

Call recordings (Call recording) should live on a separate Azure Managed Disk (Premium SSD or Standard SSD, not the OS disk). Mount it at /var/spool/asterisk/monitor and detach it before any VM rebuild. Azure Blob Storage (configured as a CIFS mount or via rclone) is a good archive target for recordings older than your retention policy window.

Azure VM snapshots capture the full OS disk. Take one after the initial VICIdial install and after every major configuration change. They are your fastest path back to a known-good state if an upgrade goes wrong. The snapshot creation itself takes a few minutes on Azure; it does not pause the VM.

For a comparison of how the self-hosted install path compares to managed hosting, see BYOI versus managed VICIdial hosting.

Self-install on Azure or managed

The Azure Marketplace has no official VICIdial image. You provision an Ubuntu 22.04 VM, run the VICIdial installer, configure your SIP trunk (SIP trunk, the Asterisk channel to your carrier), set up your dialplan, and harden the OS. Azure's additional complexity — NSG rules, public IP assignment, potential NAT Gateway interactions — adds to the initial setup time compared to simpler providers.

If you want to skip the install entirely and have a production-ready dialer in under 40 seconds, VICIfast managed plans handle provisioning, hardening, and configuration on dedicated infrastructure. You bring your carrier and leads.