RTP Ports and Firewalls: The Real Reason Your VoIP Calls Have No Audio

Signalling and media travel separately

The single most useful thing to understand about SIP is that a call uses two independent network flows. SIP signalling — the INVITE, the ringing, the 200 OK, the BYE — goes over port 5060. The audio itself travels as RTP over an entirely different set of UDP ports, negotiated per call.

This is why "the call connects but there is no audio" is such a common and confusing symptom. The connection succeeding proves only that signalling worked. The audio path is a separate question, and it is usually the firewall that answers it wrongly.

If you take one thing away: opening port 5060 alone gives you a phone system where every call is silent.

How RTP ports are allocated

When a call is set up, each side declares in its SDP which port it will listen on for audio. Asterisk picks that port from a configured range, defined in rtp.conf:

[general]
rtpstart=10000
rtpend=20000

That default range of 10001 ports is far larger than most systems need. Each concurrent call consumes two ports — one for RTP itself and one for RTCP, the control channel that carries quality statistics. So a system handling 100 simultaneous calls needs roughly 200 ports.

Narrowing the range is good practice: it makes your firewall rules tighter and easier to reason about. A sensible configuration for a mid-size system:

[general]
rtpstart=10000
rtpend=10999    ; ~500 concurrent calls, plenty of headroom

Restart Asterisk (or run module reload res_rtp_asterisk.so) after changing this, and make sure the firewall range matches exactly. A mismatch means calls work until the port allocator wanders past the end of your firewall rule — which presents as "calls fail randomly once we get busy", one of the nastier intermittent faults to chase.

Opening the ports

With firewalld:

firewall-cmd --permanent --add-port=5060/udp
firewall-cmd --permanent --add-port=10000-10999/udp
firewall-cmd --reload

With UFW:

ufw allow 5060/udp
ufw allow 10000:10999/udp
ufw reload

With raw iptables:

iptables -A INPUT -p udp --dport 5060 -j ACCEPT
iptables -A INPUT -p udp --dport 10000:10999 -j ACCEPT

If your server sits behind a NAT router, the same range must also be port-forwarded to the server's internal address. Firewall rules on the host are not enough when the packets never reach the host.

Verifying it actually works

Do not assume the rule took effect — confirm it. First, check that Asterisk is really listening where you think:

asterisk -rx "rtp show settings"

Then watch the media during a live call. Turn on RTP debugging and place a test call:

asterisk -rvvv
rtp set debug on

You should see RTP packets flowing in both directions. Traffic going out with nothing coming back is the signature of a blocked inbound path — either the firewall, the port forward, or NAT.

For a view that does not depend on Asterisk's own reporting, capture on the wire:

tcpdump -i any -n udp portrange 10000-10999

If you see no packets arriving at all, the problem is upstream of the server.

Why you cannot just open everything

It is tempting to allow all UDP and move on. Resist it. A SIP server exposed to the internet is scanned continuously, and an open server is a toll-fraud target — attackers register, place expensive international calls, and leave you the bill.

Restrict what you can. Where a carrier uses IP authentication, limit port 5060 to the carrier's addresses rather than the whole internet. Keep the RTP range as narrow as your call volume allows. And put fail2ban in front of the signalling port to shut down brute-force registration attempts.

Common failure patterns

Audio one way only. Usually NAT rather than the firewall — one side is advertising a private address in its SDP. Enable symmetric RTP so Asterisk replies to the observed source address.
No audio at all, both directions. Classic closed RTP range. Verify with tcpdump that packets are arriving.
Audio works internally, fails externally. Port forwarding or the external address setting on the PBX, not the internal firewall.
Calls fine at low volume, failing when busy. The firewall range is narrower than the Asterisk range. Make them match.
Audio cuts out after ~30 seconds. Often a NAT keepalive or session timer issue rather than ports — the mapping expires because nothing kept it open.

Frequently asked questions

What ports does VoIP actually need?

UDP 5060 for SIP signalling (5061 for SIP over TLS), plus the RTP range configured in rtp.conf — commonly UDP 10000-20000. Both must be open; signalling alone gives you silent calls.

Can I use TCP instead of UDP for RTP?

RTP is UDP by design. Retransmitting late audio is worse than losing it, so the reliability TCP provides is actively unhelpful for real-time media. Signalling can use TCP or TLS, but the media stays UDP.

How many RTP ports do I need?

Roughly two per concurrent call, plus headroom for ports not yet released. A range of 1000 comfortably supports several hundred simultaneous calls.

Why is there a separate RTCP port?

RTCP carries quality statistics — jitter, packet loss, round-trip time — alongside the media. It conventionally uses the RTP port plus one, which is why ports are consumed in pairs.