Opening the RTP port range on a cloud firewall

You open a cloud server, install VICIdial, point a SIP trunk at it, and the calls connect — but one or both sides hear nothing. Before you dig into codec settings or Asterisk logs, check the firewall. Cloud providers default to blocking all inbound traffic except what you explicitly allow, and the UDP port range that carries voice media is almost never open by default. This post walks through exactly which ports to open and why.

What RTP is and which ports Asterisk uses

RTP (Real-time Transport Protocol) RTP is the UDP-based stream that carries encoded voice from one endpoint to another. SIP negotiates the call; RTP carries the audio. Asterisk picks a random even-numbered UDP port from a configurable range for each call leg. By default that range is 10000–20000, giving you 5000 simultaneous audio streams. Each active call leg uses one port inbound and the carrier uses a corresponding port on its side.

If the cloud firewall blocks inbound UDP on those ports, the carrier's audio packets hit the firewall and are silently dropped. The SIP (Session Initiation Protocol) SIP (Session Initiation Protocol) handshake completes fine because port 5060 might already be open, so the call appears to connect. But the audio stream never arrives. This is different from a NAT problem — a closed RTP range gives you silence from the first packet, not delayed or one-directional audio.

Verifying the Asterisk RTP range

Check the range Asterisk is actually configured to use before writing firewall rules. Open /etc/asterisk/rtp.conf and look for the rtpstart and rtpend values. The standard VICIdial configuration file Conf file sets these to 10000 and 20000. Your firewall rule must match these values exactly.

[general]
rtpstart=10000
rtpend=20000

Opening the ports: ufw and cloud security groups

There are two firewall layers to think about: the OS-level firewall (ufw on Ubuntu) and the cloud provider's external security group or firewall rule. Both must allow the traffic. A rule in only one place is not enough — the cloud firewall acts before packets reach the OS.

On the OS with ufw:

ufw allow 5060/udp
ufw allow 5060/tcp
ufw allow 5061/tcp
ufw allow 10000:20000/udp

On the cloud provider side (the exact interface varies by provider), create inbound rules that permit:

Protocol: UDP  Port range: 10000-20000  Source: 0.0.0.0/0
Protocol: UDP  Port range: 5060          Source: 0.0.0.0/0
Protocol: TCP  Port range: 5060          Source: 0.0.0.0/0
Protocol: TCP  Port range: 5061          Source: 0.0.0.0/0

flowchart TD
  A[Inbound UDP packet] --> B{Cloud firewall rule?}
  B -- blocked --> C[Packet dropped silently]
  B -- allowed --> D{OS ufw rule?}
  D -- blocked --> E[Packet dropped at OS]
  D -- allowed --> F[Asterisk receives RTP]
  F --> G[Audio delivered to agent]

How many ports do you actually need

The 10000–20000 range gives 5000 even-numbered port slots, enough for 5000 concurrent call legs. A busy predictive dialing Predictive dialing campaign with 50 agents running a 3:1 dial ratio might have 150 simultaneous call legs — well within the default range. You can narrow the range if your cloud provider charges per rule or has a small rule limit, but leave at least 500 ports free per 100 concurrent calls you expect.

Confirming audio flows after the change

After updating both firewall layers, place a test call. If audio now flows in both directions, the RTP range was the issue. If you still have one-way audio, the problem is probably NAT rewriting — Asterisk advertising its private IP in the SDP instead of the public one. That is a different fix covered in the NAT audio guide. For the full picture of cloud networking requirements for VICIdial, see running VICIdial in the cloud. For details on NAT-specific one-way audio, see fixing NAT one-way audio in the cloud.

Configuring firewall rules, verifying both layers, and keeping track of port allocations is straightforward but time-consuming. If you want a VICIdial box that arrives with SIP and RTP already open and tested, see the VICIfast pricing page — managed boxes provision in under 40 seconds with all the right ports open from the start.