VoIP DDoS Protection: Why SIP and RTP Need a Different Plan

Most DDoS advice assumes a website, where a proxy in front hides the origin and filters each request. A phone system breaks all of it. SIP signalling and RTP audio run mostly over UDP, the audio goes wherever the signalling says, and a stall that a web page would hide is lost speech on a call. VoIP DDoS protection comes in two halves: network filtering upstream of your port for floods, and SIP-aware controls on your own server for attacks that look like calls.

Where VoIP traffic actually goes

RFC 3261, the SIP standard, gives SIP's default ports: 5060 for UDP and TCP, 5061 for TLS.

The audio is RTP over UDP, on no fixed port. Each side picks one from a configured range and announces it, with its IP address, in the session description (SDP) inside the SIP message; the c= line holds the address and the m= line the port.

Open exactly the range your PBX uses. The firewall in how to install Asterisk opens UDP 10000–10100, so set rtpstart and rtpend in rtp.conf to match it, or widen the rule.

Why a website DDoS proxy can't front SIP or RTP

A website DDoS proxy accepts HTTP(S), inspects each request and forwards clean ones to a hidden origin. Neither half of a call fits:

• SIP is not HTTP. An HTTP proxy cannot parse an INVITE, and it does not listen on UDP 5060.
• RTP goes where SDP says. Media flows to the address in the c= line. To hide your server, that address has to belong to a media relay or session border controller, not a web proxy.

NexonHost's website DDoS protection proxy is built for HTTP(S) sites and does not carry SIP, RTP or other arbitrary UDP. A self-hosted phone system is protected at the network edge, in front of its real address, as game servers are. Phones add a second front: valid SIP messages that guess passwords or run up your bill.

Two threats, two places to stop them

Floods at Layers 3 and 4. UDP and SYN floods, and reflection, where spoofed requests to open DNS or NTP services send large replies to you. They fill the port or the filter's packet budget before your software sees anything, so only upstream filtering helps. RFC 3261 warns that SIP proxies and user agents can be reflectors too, via a forged source address and Via header.

SIP-method attacks. REGISTER, INVITE or OPTIONS floods, extension scans, password guessing, and toll fraud, where a compromised account dials expensive destinations on your bill. For SIP, this is the application layer: each packet is a valid SIP message, and a filter that does not parse SIP cannot tell it from your phones.

The packet arithmetic of a phone call

G.711 (PCMU and PCMA), the standard telephone codec, sends 8,000 samples a second at 8 bits each, packed by default every 20 ms (RFC 3551). So:

• 1 ÷ 0.020 s = 50 packets a second in each direction.
• 8,000 × 0.020 = 160 samples, so 160 bytes of audio per packet.
• Add 12 bytes of RTP header (RFC 3550), 8 of UDP (RFC 768) and 20 of IPv4 (RFC 791): 160 + 12 + 8 + 20 = 200 bytes.
• 200 × 8 bits × 50 = 80,000 bit/s: 80 kbit/s per direction at the IP layer.

A thousand concurrent calls is 50,000 packets a second and 80 Mbit/s each way. If the PBX stays in the media path between a phone and a trunk, each call has two legs, so double both.

So a VoIP server's load is packet-heavy, not bandwidth-heavy: 80 Mbit/s is 8% of a 1 Gbps port. Filters run out of packets before bandwidth when packets are small, as Gbps vs Mpps shows. Attack packets aimed at your RTP range can be the size of real audio: a million a second is 1,000,000 × 200 × 8 = 1.6 Gbps, more than a 1 Gbps port carries, so they must be dropped upstream. RTP does not guarantee delivery (RFC 3550), and each lost G.711 packet is 20 ms of missing audio.

What network-level protection handles

Network DDoS protection filters at Layers 3 and 4, upstream of your port: floods, reflection, malformed packets and SYN floods. At NexonHost, every Linux VPS and every dedicated server includes it:

What it does not do: parse SIP. It does not stop a REGISTER flood from real addresses or a password-guessing run, and it cannot tell well-formed UDP at an open RTP port from a caller. Before you put phones behind any provider, us included, ask:

• Is filtering always inline, or switched on once an attack is detected?
• What happens to RTP while mitigation runs: does traffic take a different path, and what does that do to jitter on live calls?
• What happens when an attack exceeds the tier: more filtering, a temporary null-route of the address, or an upgrade?

Under attack now? Start with what to do when your server is under DDoS attack.

SIP-aware controls on your own server

SIP-method floods and fraud are stopped on the PBX, or on a SIP proxy in front of it:

• Kamailio pike counts requests per source IP. By default it samples every 2 seconds at a density of 30; the docs put the practical limit at 30 to 90 requests per sample for IPv4, 30 to 240 for IPv6. It only reports; your routing script decides whether to drop.
• Kamailio ratelimit limits by SIP method, such as INVITE or REGISTER, rather than by source, and its documented example answers the excess with a 503.
• fail2ban ships an Asterisk filter for failed registrations, wrong passwords and ACL rejections, and an [asterisk] jail on ports 5060 and 5061 that bans for 10 minutes after 10 failures in 10 minutes, once enabled; FreeSWITCH has a jail too. FreePBX's Intrusion Detection runs fail2ban; Sangoma's version 13 documentation gives a default 1,800-second ban and 600-second window.
• Allowlist by IP. In Asterisk's PJSIP, an identify section ties your trunk to its provider's addresses (identifying, not blocking), and an acl section with deny=0.0.0.0/0.0.0.0 plus permit lines for your trunk provider and offices applies to all inbound SIP. Remote staff can come in over a private VPN server.
• Fence off toll services. Asterisk's documentation warns that misconfiguration can let outsiders run up charges, and says to keep outgoing and toll services out of contexts that incoming channels reach.

Moving SIP off 5060 may quieten scans that only try 5060, but it is not protection: SIPVicious's svmap scanner takes port ranges (its manual's example is -p5060,5061,8000-8100).

Choosing a VPS or dedicated server for VoIP

A small office PBX fits a Linux VPS, but check the quota on metered plans: a G.711 call-hour is 80,000 × 3,600 ÷ 8 = 36 MB each way at the IP layer. The unmetered Linux VPS plans start at €18 a month on a 1 Gbps port.

A dedicated server suits call centres and anyone running Kamailio in front of several PBXs: no neighbours on the CPU, 100 Gbps of filtering included, and extra IPv4 addresses at €3 a month each, up to five, to keep the SIP edge off your website's address.

When a hosted service is the better buy

Self-hosting buys control: your own dialplan, integrations, recordings on your hardware. It also makes you the security team. If nobody will patch Asterisk or FreePBX, read the fail2ban log and notice a night of calls to premium numbers, don't self-host:

• UCaaS or a hosted PBX if an office needs phones, voicemail and queues. The SIP edge, patching and fraud monitoring become the provider's job; ask how it handles DDoS.
• A SIP trunk into a locked-down PBX if you need your own PBX: accept SIP only from the trunk provider's addresses, using the ACLs above.

Where NexonHost fits

For VoIP DDoS protection on a self-hosted PBX or SIP proxy, NexonHost covers the network half. Every Linux VPS includes 100 Gbps from €9 a month. Every Xeon and EPYC build on the DDoS protected dedicated server page includes 100 Gbps from €129 a month, and either can be raised to as much as 10 Tbps.

The SIP half, pike, ratelimit, fail2ban and ACLs, runs on your server. The website protection proxy does not carry SIP or RTP, so don't buy it for phones. Start on a one-month term.

Prices are as of 19 October 2026 (DDoS tiers 23 October 2026), in euros excluding VAT. Check the product page before you order.

Sources

• RFC 3261 — SIP: Session Initiation Protocol, IETF, retrieved 19 October 2026: default ports 5060 (UDP, TCP) and 5061 (TLS) in sections 18.1.1 and 18.2.1; reflection via forged source address and Via in 26.1.5.
• RFC 3550 — RTP: A Transport Protocol for Real-Time Applications, IETF, retrieved 19 October 2026: 12-octet fixed header (section 5.1); no delivery guarantee (section 1).
• RFC 3551 — RTP Profile for Audio and Video Conferences, IETF, retrieved 19 October 2026: 20 ms default packetisation (section 4.2); G.711 PCMU/PCMA at 8 bits per sample (section 4.5.14), 8,000 Hz (table 4).
• RFC 768 — User Datagram Protocol, IETF, retrieved 19 October 2026: 8-byte UDP header.
• RFC 791 — Internet Protocol, IETF, retrieved 19 October 2026: minimum IPv4 header of five 32-bit words, 20 bytes.
• RFC 8866 — SDP: Session Description Protocol, IETF, retrieved 19 October 2026: the c= connection line (section 5.7) and m= media line with the port (section 5.14).
• rtp.conf.sample — Asterisk source repository, retrieved 19 October 2026: rtpstart=10000, rtpend=20000; defaults 5000 and 31000 when unset (DEFAULT_RTP_START and DEFAULT_RTP_END in res/res_rtp_asterisk.c).
• switch_rtp.c — FreeSWITCH source repository, retrieved 19 October 2026: RTP_START_PORT 16384, RTP_END_PORT 32768 (the compiled defaults; the shipped switch.conf.xml leaves rtp-start-port and rtp-end-port commented out).
• pike module — Kamailio documentation, stable branch, retrieved 19 October 2026: per-source tracking, sampling_time_unit default 2, reqs_density_per_unit default 30, practical blocking limit between x and 3x for IPv4 and x and 8x for IPv6, reporting only.
• ratelimit module — Kamailio documentation, stable branch, retrieved 19 October 2026: per-request-type limiting, 503 example for INVITE, REGISTER and SUBSCRIBE.
• asterisk.conf filter — fail2ban repository, retrieved 19 October 2026: failure patterns matched.
• jail.conf — fail2ban repository, retrieved 19 October 2026: [asterisk] jail on ports 5060 and 5061, maxretry 10; default bantime and findtime 10 minutes; [freeswitch] jail; all jails disabled by default.
• PBX GUI — System Admin: Intrusion Detection, Sangoma documentation, retrieved 19 October 2026: Fail2Ban, ban time 1,800 s and find time 600 s by default (written for PBX GUI version 13).
• pjsip.conf.sample — Asterisk source repository, retrieved 19 October 2026: identify with match= for trunks; acl with deny and permit, applied to all inbound res_pjsip traffic.
• Important Security Considerations — Asterisk documentation, retrieved 19 October 2026: warning that improper configuration can allow unauthorised use and charges.
• Dialplan Security — Asterisk documentation, retrieved 19 October 2026: keep outgoing and toll services out of contexts reachable from incoming channels.
• svmap(1) — SIPVicious manual page, Debian, retrieved 19 October 2026: -p port ranges.
• NexonHost store, retrieved 19 October 2026: VPS and dedicated base prices, unmetered VPS price, extra IPv4 price.
• NexonHost store, retrieved 23 October 2026: VPS and dedicated DDoS protection tiers and prices.
• Computed: 3 × 30 = 90 and 8 × 30 = 240 requests; 1 ÷ 0.020 = 50 packets/s; 8,000 × 0.020 = 160 bytes; 160 + 12 + 8 + 20 = 200 bytes; 200 × 8 × 50 = 80 kbit/s; 50 × 1,000 = 50,000 packets/s; 80 × 1,000 = 80,000 kbit/s = 80 Mbit/s; 80 ÷ 1,000 = 8%; 1,000,000 × 200 × 8 = 1.6 Gbps; 80,000 × 3,600 ÷ 8 = 36 MB.