A request for “500 or 1,000 concurrent calls, one server or two, our hardware or hosted” still leaves the second number blank. Concurrent calls (CC) are the calls up at one moment: ringing, setting up, or in talk. Calls per second (CPS) are the new attempts in that second, and a failed attempt counts. A burst of short failures can exhaust CPS while the CC graph looks calm.
The layout is MOR, the Class 5 softswitch, or M4, the Class 4 softswitch; one server or several; your hardware or hosted. Capacity and hardware figures below come from Softswitch performance and Recommended hardware. The product split comes from MOR vs M4. If a capacity figure changes, Kolmisoft updates the wiki. Use the wiki as the source of truth.
Calls per second vs concurrent calls is the short glossary. When your voice business needs more than 1,000 CPS is the article for attempt rates past that line. How do you select a softswitch based on concurrent calls? is older background. This page replaces it for the layout decision.
Measure the two numbers before you pick a box
Write down the busy hour, not the month.
- Peak CC, ringing and setup included.
- Peak CPS, failed attempts included.
- Average call duration (ACD) on calls that connect.
- Traffic type: retail, wholesale, calling cards, callback, or call-center termination.
- Audio through the switch, or signalling with the audio going end to end.
- Recording, transcoding, or IVR on that same machine.
- Where you expect the two peaks to sit in 12 months.
Suppose the busy hour shows 200 calls up and 40 new attempts each second, most of them failing. CC sits inside a 500-call band. CPS does not. That pattern is the one in why a dialer gets 503s when channels are still free.
Do not plan as if maximum CC and maximum CPS arrive together. Ideal conditions on the performance page mean no codec transcoding, no call recording, a quiet web interface, and no heavy reports or invoice runs beside the calls. Current as of November 2026, see Softswitch performance.
Capacity bands
These are estimates for suitable hardware. They are not a guarantee. A license can allow fewer concurrent calls than the hardware can carry. Raising that concurrent-call allowance does not change the CPS the hardware can process. The license and the machines both have to cover the traffic. Current as of November 2026, see Softswitch performance.
| Layout | Concurrent calls | CPS |
|---|---|---|
| MOR, one server | Up to 500 | Closer to 20 in ordinary use; up to 50 under ideal conditions |
| MOR, several servers | Up to 2,000 | Closer to 60 in ordinary use; up to 100 under ideal conditions |
| M4, one server | Up to 500 | Up to 100 |
| M4, scalable multi-server | Up to 10,000 | Up to 1,000 |
“Several servers” on the MOR row is the multi-server band. It is not any second machine you add. The 10,000 CC and 1,000 CPS line is the scalable M4 design.
M4 system architecture separates media through the switch from signalling with the audio end to end. Current as of November 2026, one M4 server is CPS 100, 500 CC with media, 1,000 CC without media, and 400 to 500 CC with transcoding. GUI use on that box cuts CC and CPS a lot. The page marks that layout for light testing, not for production. Two M4 servers, with signalling and media split from core, GUI, and database, are CPS 300, 2,000 CC with media, and 4,000 CC without media. The scalable design is CPS 1,000, about 4,000 CC on each media server, three media servers at most, a cap of 10,000 CC, and 1,200 to 8,400 CC with transcoding. Each rectangle is one physical server.
The performance page also records two MOR workloads. Current as of November 2026, they are observed traffic, not a lab limit for the next install. One server, 24 cores, almost no web interface: up to 500 CC and 1,500 attempts in a minute, an average of 25 attempts per second across that minute. A shorter peak inside the minute can sit elsewhere. A balancer, three call servers, and a separate database: 1,200 CC and the same 1,500 attempts in a minute. The page gives that as the load it saw, not as the ceiling.
MOR or M4
Match the features, then check the band. The grid is on MOR vs M4. Class 4 and Class 5 are different jobs.
MOR is the retail and PBX-side platform: IVR, recordings, resellers, calling cards, callback, an auto-dialer, and the rest of the PBX list. MultiSIP is on MOR, so several people can place outbound calls with one SIP username and password. Choose MOR when many phones sit behind NAT, including several registrations from one address. MOR speaks SIP, H.323, and IAX2. The engine is Asterisk. The comparison page says that engine is not built for very high call volume. Use the 500 CC row or the 2,000 CC row, and the CPS cell on that row.
M4 is the wholesale, carrier, and call-center termination platform. The engines are Kamailio, SEMS, and RTPEngine. The protocol is SIP. Recordings, resellers, the PBX list, calling cards, callback, and MultiSIP are not on M4. Call-center features in that comparison sit on a platform outside the switch. The 10,000 CC and 1,000 CPS line belongs to the scalable M4 design on the performance page.
MOR for the retail edge and M4 for the wholesale core is a conversation with Vilius, not an extra row in the table.
One server or several
One server is the 500 CC row and that product’s CPS cell. Take the server down for maintenance and every call stops with it.
Three pages, current as of November 2026, describe that row in different terms. Pricing structure lists MOR on one server at up to about 500 CC and up to about 50 CPS, ordinary use closer to about 20, and calls it a fit for a smaller provider or a deployment that is still new. MOR implementations draws one server at up to 500 CC, tells you to keep it as a test, and says it is not safe for a live business. The same page calls the two-server redundant drawing the most popular and the most stable. That drawing is still up to 500 CC. M4 system architecture marks one M4 server for light testing, not for production.
Leave one server when the peaks pass the band, or when the service needs a standby. On MOR, the implementations page lists the balancer drawing at up to 2,000 CC and 100 CPS: call processing apart from the database and the web interface. A two-server high-availability pair stays at 500 CC. A four-server redundant drawing stays at 1,000 CC.
On M4, two servers are the 2,000 CC and 300 CPS step. 10,000 CC and 1,000 CPS is the scalable drawing.
A live extra call server can raise the call count. A standby does not. It keeps the service up when one machine fails. Current as of November 2026, Softswitch performance. The failover write-up is high availability, redundancy, and failover.
Hardware, if the servers are yours
Use the production column on Recommended hardware, not the test column. Current as of November 2026.
Clean Rocky 9 minimal, clock on UTC, locale en_US. At least 8 CPU cores, 32 GB of RAM or more, 500 GB or more of SSD or NVMe in RAID 1. Put the disk on /. A small /boot is fine. Do not give /home or /var their own partitions. The test column is a 4-core / 8-thread Xeon, 16 GB of RAM, and a 100 GB SSD. Live traffic on that column will not match the capacity table.
On M4, past 700 CC, the page names Intel I210, I350, or X550T. It calls Realtek RTL8111/8168/8411 and Intel 82574L weak.
Roles on that page:
| Role | What to size |
|---|---|
| MOR call server | CPU, 4 GB RAM. SSD does not speed the calls. With a proxy: public IP for SIP and RTP, not behind NAT, close to the database. |
| MOR database | SSD, required with more than one call server. 100 GB or more. 8 GB RAM minimum. A UPS if more than one database server, because a power cut breaks replication. |
| MOR proxy | 4 GB RAM, 40 GB disk, public IP, not behind NAT. |
| M4 database and core | SSD, start at 400 GB or more, 16 GB RAM minimum, 32 GB in production. |
| M4 proxy and media | CPU. A smaller disk is enough. |
The page lists tests on Proxmox, VMware, VirtualBox, XEN, AWS, and Azure. Keep every virtual machine of a multi-server design off one physical host. Use dedicated servers, or one virtual machine per dedicated host.
A redundant pair shares a subnet, can broadcast and receive on UDP port 694, and holds one virtual IP on one server at a time. Kolmisoft does not build a custom failover when the network cannot do that. Do not split the pair across two data centers. There is no shared subnet, so the path is a VPN or DNS, and broken MySQL replication is a split brain you cannot repair without losing calls and billing data. Two MOR servers in two places can each start billing alone if the link breaks. The M4 architecture page describes a four-server, two-site drawing with two active IPs and DNS SRV. The hardware page does not recommend that drawing.
When hosted fits
On a hosted system, Kolmisoft runs the OS, the RAID, the NIC, and replication. A disk, NIC, or replication failure on that service is Kolmisoft’s infrastructure work. The CC and CPS bands stay where they are.
Choose hosted for a faster start, or for a pilot, when you do not want to buy the machines first. MOR vs M4 describes the pilot as installation, technical support, and personal training so you can run your own call flows. The performance page treats a pilot on your real traffic and your real features as the check that the layout holds.
Signs the layout you have is too small
- Peak CC sits near the ceiling of the band on busy days.
- Setups are rejected, or post-dial delay climbs, while CC still has room. On a dialer, that is a CPS problem. See calls per second vs concurrent calls.
- Recording, transcoding, and a busy web interface share the box that carries the audio. That mix is outside ideal conditions, so leave the top CPS cell out of the plan.
- A standby or a second data center is in the plan. Count the standby as failover. Do not add it to CC.
- The new load is wholesale attempt-rate, and the retail feature list is no longer the reason you are on MOR. Read when your voice business needs more than 1,000 CPS if the rate is past that line.
What to send before anyone draws a server
“1,000 ports” names CC and skips CPS. Send peak CC, peak CPS with failures included, ACD, traffic type, whether media, transcoding, recording, and IVR are on, the server spec or the words “prefer hosted,” and where the peaks should sit in 12 months.
A new enquiry uses the pricing form. If a conversation is already open, write to Vilius from the contact page: b2bsales@kolmisoft.com.
If a number here and a number on Softswitch performance or Recommended hardware disagree, trust the wiki page. Kolmisoft updates the page. This post is then updated from the page.
Send the two peaks
Send peak concurrent calls, peak CPS, and whether you want hosted or your own servers.
If the question is billing fit rather than server size alone, start from VoIP billing software and the infrastructure section there, which points back to the hardware and performance wiki pages.