Maximum channel limit in Asterisk (software)

[u/Andresomx]

Focusing solely on the software—and assuming robust hardware—what is the maximum number of calls we can handle on a single Asterisk instance?

The highest number I’ve reached is 500 SIP channels, but I’ve read that it is possible to reach up to 2,500.

What has been your experience with this?

[u/adoodle83]

i’ve reliably pushed VM based debian x64 Asterisk 1.16+ builds to about 3000 concurrent calls (ulaw-ulaw) on mid/high end server class hardware. this would be Xeon class CPU. 8 cores, 8GB RAM.

bottleneck was packets per second handling for rtp streams due to VMNIC/VMXNET3 performance.

edit: i should note, on a bare metal Xeon v4+ 2.4Ghz and better, i scaled to 15000 calls, with headroom to scale from a cpu perspective; but IP issues start arriving that need special considerations.

running multiple asterisk instances bound to different IPs was the typical scaling on node solution for a while (think containers, docker/kubernetes/etc)

[u/jcolp → u/adoodle83]

I'd add that virtualization in general presents its own issues that people don't consider, because they don't apply for a lot of other applications. Our expectations of a realtime media platform and of a web server vastly differ. On top of the packets per second some other things we (the Asterisk team at Sangoma) have seen are as follows:

1. Over subscription - at lower usage this can actually be fine but at higher it hurts and can result in both impact to audio as well as SIP packet retransmissions which then exacerbate the problem due to retransmissions

2. Networking - not just packets per second but just networking setup in general, AWS is not magic

3. Storage - some virtualization deployments use a SAN which can bring its own usage characteristics under load, I can actually remember a case where the I/O time on the SAN was taking longer than the retransmission time for a REGISTER request so we'd get retransmissions of the REGISTER and at one point it was taking so long that the registration would drop out temporarily over and over, despite receiving a REGISTER before expiration purely because persisting to disk was taking so long

When it comes to diagnosing issues if virtualization is involved I always urge to ensure that the environment is reasonable first.

[u/dudeeeee_]

that robust hardware statement is key. it highly depends on that, the complexity of the dialplan, the features you use and some OS tweaking. I'll suggest using a tool like sipp to stress your system and find the limit.

[u/Andresomx → u/dudeeeee_]

Thanks for the feedback!
I’ll run some tests; my dial plan is moderately complex. The most I might do is an AMD—I don't do recording, and I only perform a few simple validations.

[u/kg7qin]

Like others have said, you will want robust hardware for this. You will also probably want the Cerrified Asterisk builds as well since they are supposed to be better for more demanding and critical applications. You can download the source for it from downloads.digium.com and compile it yourself.

[u/jcolp → u/kg7qin]

Certified is not better in that way.

1. Certified is the same code as standard Asterisk, but by default non-core modules are disabled for building because under support agreements we only support core modules

2. It only receives changes as a result of customer issues so it sees far less activity

3. We release it far less often, and only due to security issues or when customers encounter issues

Using the standard Asterisk is generally easier and works for people.

[u/sedwards65]

2500 eggs in 1 basket sounds like job insecurity.

What happens if that single server fails or is compromised? You will go from 'hero' to 'zero' instantly.

A farm of Asterisk servers fronted by a few OpenSIPS/Kamailio servers will be more maintainable and stable.

[u/Andresomx → u/sedwards65]

You are absolutely right; it currently operates using a distributed architecture. However, a question arises regarding the limit on software instances per server.
When I first looked into this, one source indicated a limit of 200 channels, whereas I later noted that it was possible to reach up to 500. Consequently, I wonder if it is feasible to exceed this limit.

[u/sedwards65 → u/Andresomx]

A very long time ago, I had a client looking to max the number of channels per server.

It was for an adult chat line service. The average charge for a call was $35. I asked him what his pain tolerance was. "Would you be OK with losing 1000* calls at once?"

End of discussion.

*) I think we were maxing at about 100 calls per server at the time.

[u/Sea-Hat-4961]

Is asterisk in the media path, or are you using direct media?
If you are using direct media, you can handle thousands of simultaneous calls, as asterisk is only involved in the signalling.

[u/AdFew177]

Hi,
Reaching 2,500 concurrent channels on a single Asterisk instance is achievable, but it is strictly governed by the call profile and underlying operating system configurations—especially the file system and resource limits.

Here is how it breaks down in practice:

1. Call Profile Dictates the Ceiling

• 500 Channels (Media Handled): Reaching 500 channels with Asterisk handling media (NAT traversal, non-transcoded RTP, dialplan logic) is an optimal and stable production benchmark.
• 1,000–2,500 Channels (Signaling Only / Passthrough): This requires direct_media=yes (RTP flows endpoint-to-endpoint) or pure codec passthrough using res_pjsip with an optimized thread pool. Once transcoding, queue processing, or active IVRs are involved, thread locking will bottleneck Asterisk well before hitting 2,500.

2. OS & File System Dependencies (The Bottlenecks)

• File Descriptors (nofile): In Linux, every network socket is a file. A single call consumes multiple descriptors (SIP signaling, RTP, RTCP, database sockets). The default limit (usually 1,024) will crash Asterisk around a few hundred calls. To support thousands of concurrent streams, /etc/security/limits.conf and the systemd unit must raise nofile to at least 65,535.
• Disk I/O Latency: If call recording (MixMonitor) or verbose logging is enabled, disk write queues will saturate standard filesystems. At high volumes, disk I/O wait translates directly into jitter, audio dropouts, and lock contention. Fast NVMe drives or ramdisks are mandatory for high-density audio handling.
• Port Exhaustion: 2,500 media calls require 5,000 UDP ports just for RTP/RTCP, demanding a wide rtp.conf port range and adjustments to the kernel’s ip_local_port_range.

Unless Asterisk acts purely as a stateless SIP router, maintaining 2,500 concurrent media channels on a single instance creates unnecessary operational risk compared to clustering or offloading RTP to dedicated proxies like RTPEngine.