Scaling a VOS3000 scaling deployment to handle thousands of concurrent calls requires far more than simply upgrading server hardware. Many operators hit performance walls at 500 or 1000 concurrent calls and assume they need a bigger server, when the real bottleneck is often CentOS kernel parameters, MySQL configuration, or VOS3000 system parameter settings that were never optimized for high traffic. Understanding the actual limits of VOS3000 and the specific tuning required at each capacity level is the difference between a platform that handles 5000+ concurrent calls smoothly and one that crashes at 800 calls during peak hours.
This guide provides proven VOS3000 scaling methods based on real production deployments and features documented in the official VOS3000 V2.1.9.07 Manual, including Process Monitor auto-restart (Section 2.12.9), Disaster Recovery master/slave setup (Section 2.15), and critical softswitch parameters (Section 4.3.5.2). We are honest about VOS3000’s actual limitations and do not claim features that do not exist. For professional assistance with scaling your VOS3000 deployment, contact us on WhatsApp at +8801911119966.
Before planning a scaling strategy, you must understand the realistic capacity limits of a single VOS3000 server. These limits depend on whether VOS3000 is processing media (with media proxy mode) or only handling signaling (without media mode). The difference is dramatic because media processing consumes significantly more CPU and memory resources than signaling-only operation.
In “with media” mode, VOS3000 proxies RTP media streams between the calling and called parties. This means every audio packet passes through the VOS3000 server, which provides visibility into call quality and the ability to transcode codecs, but requires substantial CPU and bandwidth resources. In “without media” mode, VOS3000 only handles SIP signaling and lets RTP media flow directly between endpoints. This dramatically reduces CPU load and bandwidth consumption on the server, allowing much higher concurrent call capacity.
| 📊 Capacity Metric | 🎵 With Media Mode | 📡 Without Media Mode |
|---|---|---|
| Max Concurrent Calls (8 core, 32GB) | ~3,000-5,000 | ~10,000-20,000 |
| Max CPS (calls per second) | ~100-200 | ~300-500 |
| CPU utilization per 1000 CC | ~20-30% | ~5-10% |
| Bandwidth per 1000 CC (G711) | ~170 Mbps | ~5 Mbps (signaling only) |
| Transcoding overhead | Very high (G729 uses licensed DSP) | None |
For most carrier deployments, the without-media mode provides the highest capacity. Use with-media mode only when you specifically need transcoding, call recording, or media-level debugging. For bandwidth calculation details, see our VOS3000 RTP media guide.
Choosing the right hardware is the foundation of VOS3000 scaling. The following recommendations are based on production benchmarks for different traffic levels, helping you select the appropriate server for your current and projected capacity needs.
| 📊 Traffic Level | 💻 CPU | 🧠 RAM | 💾 Storage | 📶 Max CC |
|---|---|---|---|---|
| Starter | 4 Core Xeon | 8 GB | 500 GB HDD | 500 |
| Professional | 8 Core Xeon E5 | 16 GB | 500 GB SSD | 1,500 |
| Enterprise | 16 Core Xeon E5 | 32 GB | 1 TB SSD | 5,000 |
| Carrier | 2x 16 Core Xeon | 64 GB | 2 TB NVMe | 10,000+ |
SSD storage is critical for high-traffic VOS3000 scaling because the CDR database generates thousands of insert operations per minute. HDD storage becomes a bottleneck at high insert rates, causing CDR write delays that cascade into billing delays and system instability. For pre-configured VOS3000 servers, see our VOS3000 server rental page.
Default CentOS 7 kernel parameters are designed for general-purpose servers, not real-time VoIP traffic. Without kernel tuning, VOS3000 will hit UDP buffer limits, file descriptor caps, and connection tracking bottlenecks long before the hardware reaches its actual capacity. These tuning parameters are documented in our CentOS 7 kernel tuning guide and are essential for any VOS3000 scaling effort.
# /etc/sysctl.conf - VOS3000 High Traffic Optimization # UDP buffer sizes (critical for RTP media) net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.udp_mem = 1024000 8738000 16777216 net.ipv4.udp_rmem_min = 16384 net.ipv4.udp_wmem_min = 16384 # TCP buffer and connection tuning net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.core.somaxconn = 65535 net.core.netdev_max_backlog = 10000 net.ipv4.tcp_max_syn_backlog = 16384 # Connection tracking (increase for high CPS) net.netfilter.nf_conntrack_max = 1048576 net.netfilter.nf_conntrack_tcp_timeout_established = 7200 # File descriptors fs.file-max = 2097152 # Port range for outbound connections net.ipv4.ip_local_port_range = 1024 65535 # Apply changes sysctl -p
| ⚙️ Parameter | 📋 Default | 🔧 Tuned Value | 📝 Impact |
|---|---|---|---|
| net.core.rmem_max | 212992 | 16777216 | Prevents RTP packet loss |
| fs.file-max | 79580 | 2097152 | Supports more open sockets |
| nf_conntrack_max | 65536 | 1048576 | Supports high CPS rates |
| somaxconn | 128 | 65535 | More pending connections |
VOS3000 softswitch parameters control the maximum concurrent calls, CPS rate, and CDR write behavior. These parameters must be adjusted to match your server capacity and traffic patterns. Navigate to Operation Management > Softswitch Management > Additional Settings > System Parameter to modify these values, as documented in VOS3000 Manual Section 4.3.5.2.
| ⚙️ Parameter | 📋 Default | 🔧 Recommended | 📝 Purpose |
|---|---|---|---|
| SS_MAXCPS | 200 | Match hardware capability | Max calls per second |
| SS_CDR_FILE_WRITE_INTERVAL | 60 | 30 (high traffic) | CDR file flush interval (seconds) |
| SS_CDR_FILE_WRITE_MAX | 1000 | 500 (high traffic) | Max CDR records per write batch |
| SS_NO_MEDIA_HANGUP | 0 | 30-60 (without media) | No-media hangup timer (seconds) |
| SS_MAX_CALL_DURATION | 0 (unlimited) | 7200 (2 hours max) | Prevents stale calls consuming resources |
Setting SS_MAXCPS correctly is crucial. If set too high for your hardware, the server becomes overloaded and call quality degrades. If set too low, legitimate calls are rejected during peak traffic. Monitor your Server Monitor statistics (Section 2.12.10) and adjust SS_MAXCPS based on actual CPU and memory utilization patterns.
At high traffic levels, service stability becomes critical. VOS3000 includes a Process Monitor feature (Section 2.12.9) that automatically detects and restarts crashed services, ensuring continuous operation even when individual processes encounter errors under heavy load.
Navigate to Operation Management > Softswitch Management > Process Monitor to view and configure the auto-restart behavior. The Process Monitor continuously watches all VOS3000 core processes including the SIP signaling engine, RTP media proxy, billing engine, and database connectors. When any process stops responding or crashes, the Process Monitor automatically restarts it within seconds, minimizing service disruption.
For VOS3000 scaling, the Process Monitor is essential because high traffic increases the probability of process failures. Without auto-restart, a crashed process at 3 AM during peak traffic could result in hours of downtime before an operator notices and manually restarts the service. With Process Monitor enabled, the same crash is resolved in under 30 seconds with minimal call disruption. Configure the monitor to send email alerts when it performs an auto-restart so you can investigate the root cause during business hours.
MySQL database performance is the most common bottleneck in high-traffic VOS3000 deployments. Every call generates at least one CDR record, and at 200 CPS, that means 12,000 CDR inserts per minute. The database must handle this insert rate while simultaneously serving CDR queries, billing calculations, and account balance lookups without introducing latency into the call processing path.
Key MySQL settings for VOS3000 scaling include setting innodb_buffer_pool_size to 50-70% of total RAM, increasing innodb_log_file_size to 512M or larger for high write throughput, and configuring innodb_flush_log_at_trx_commit to 2 for better write performance (with slightly increased crash risk). Additionally, implement a CDR archival strategy that moves old records to archive tables or a separate database, keeping the active CDR table small enough for fast queries. For detailed MySQL optimization, see our VOS3000 database optimization guide and our CDR MySQL cleanup guide.
| ⚙️ MySQL Setting | 🔧 High-Traffic Value | 📝 Purpose |
|---|---|---|
| innodb_buffer_pool_size | 50-70% of RAM | Cache table data in memory |
| innodb_log_file_size | 512M | Faster transaction logging |
| innodb_flush_log_at_trx_commit | 2 | Better write performance |
| max_connections | 1000 | Handle concurrent connections |
| innodb_io_capacity | 2000 (SSD) / 200 (HDD) | Match disk I/O capability |
When a single VOS3000 server cannot handle your traffic, you need a multi-server architecture. It is important to understand that VOS3000 does not have native horizontal scaling or built-in load balancing. Scaling to multiple servers requires external components and architectural planning.
The standard approach for VOS3000 scaling beyond a single server is to deploy multiple independent VOS3000 instances, each handling a portion of the total traffic. Traffic distribution is achieved through a SIP load balancer or DNS round-robin that distributes incoming SIP signaling across the VOS3000 servers. Each VOS3000 instance operates independently with its own database, and traffic is partitioned by destination prefix, customer account, or geographic region.
| 🏗️ Architecture | 📝 Description | 📊 Max Capacity | ⚠️ Complexity |
|---|---|---|---|
| Single server | One VOS3000 instance | ~5,000 CC with media | Low |
| Prefix partitioned | Different prefixes on different servers | ~5,000 CC x N servers | Medium |
| SIP load balancer | Kamailio/OpenSIPS distributes traffic | ~5,000 CC x N servers | High |
| Master/Slave DR | Active-passive failover pair | Same as single server | Medium |
VOS3000 Manual Section 2.15 documents the Disaster Recovery (DR) system, which provides active-passive failover between two VOS3000 servers. In this configuration, the master server handles all traffic while the slave server remains in standby mode, continuously synchronizing its database with the master. If the master server fails, the slave takes over automatically, providing business continuity for critical carrier operations.
The DR system is not a scaling solution since only one server is active at a time, but it is essential for high-availability deployments where downtime costs exceed the cost of a second server. The synchronization includes all configuration data, account information, rate tables, and CDR records, ensuring the slave has a complete and current copy of all data needed to take over operations seamlessly.
Network bandwidth is a critical factor in VOS3000 scaling, particularly in with-media mode where all RTP streams pass through the server. Calculating your bandwidth requirement accurately prevents network congestion that causes packet loss, jitter, and poor call quality.
| 🎵 Codec | 📊 Bitrate (kbps) | ➕ With Overhead (kbps) | 📶 Per 1000 CC (Mbps) |
|---|---|---|---|
| G.711 (PCMU/PCMA) | 64 | ~85 | ~170 |
| G.729 | 8 | ~30 | ~60 |
| G.723.1 | 5.3/6.3 | ~22 | ~44 |
| G.722 | 64 | ~85 | ~170 |
Always calculate bandwidth based on the codec with overhead (including IP, UDP, and RTP headers), not just the raw codec bitrate. A common mistake is to calculate based on G.711’s 64 kbps raw bitrate, which underestimates the actual bandwidth by approximately 33% when accounting for protocol overhead. For professional capacity planning assistance, contact us on WhatsApp at +8801911119966.
A single VOS3000 server can handle approximately 3,000-5,000 concurrent calls in with-media mode or 10,000-20,000 concurrent calls in without-media mode, depending on hardware specifications. These are realistic production figures, not theoretical maximums. Actual capacity depends on CPU speed, RAM size, disk I/O performance, network bandwidth, and the codec mix being used. For higher capacity, you need a multi-server architecture with external load balancing.
No, VOS3000 does not include native horizontal scaling or built-in load balancing. Scaling beyond a single server requires deploying multiple independent VOS3000 instances and using an external SIP load balancer such as Kamailio or OpenSIPS to distribute traffic across them. Each instance operates independently with its own database. Traffic can also be partitioned by prefix or customer to distribute load without a load balancer.
The VOS3000 DR system (Manual Section 2.15) uses an active-passive master/slave configuration. The master server handles all traffic, while the slave continuously synchronizes its database. If the master fails, the slave takes over automatically. This provides high availability, not scaling, since only one server is active at a time. For help setting up DR, contact us on WhatsApp at +8801911119966.
At high traffic levels, VOS3000 generates thousands of CDR insert operations per minute. HDD storage cannot keep up with this write rate, causing CDR write delays that cascade into billing delays and potential system instability. SSD and NVMe storage provides the necessary I/O operations per second (IOPS) to handle high-volume CDR writes while simultaneously serving database queries. For any deployment exceeding 500 concurrent calls, SSD storage is strongly recommended.
In with-media mode, VOS3000 proxies RTP audio streams, which requires significant CPU and bandwidth. In without-media mode, VOS3000 only handles SIP signaling while media flows directly between endpoints. Without-media mode provides approximately 3-4x higher concurrent call capacity on the same hardware because the server does not process audio packets. Use without-media mode when you do not need transcoding or media-level debugging.
Use the VOS3000 Server Monitor (Section 2.12.10) to track CPU, memory, and process statistics in real time. Configure the Alarm System (Section 2.11) to alert you when thresholds are exceeded. Monitor MySQL performance using standard tools like mysqladmin status and slow query logs. Review CDR query response times as an indicator of database health. Regular monitoring allows you to identify and address bottlenecks before they cause service degradation.
Scaling VOS3000 for high-traffic carrier operations requires expertise in CentOS tuning, MySQL optimization, network architecture, and VOS3000 system parameters. Our team has deployed VOS3000 platforms handling thousands of concurrent calls for carriers worldwide.
Contact us on WhatsApp: +8801911119966
We offer complete VOS3000 scaling services including capacity planning, server configuration, kernel tuning, database optimization, and multi-server architecture design. Whether you are planning your first deployment or scaling an existing platform to handle carrier-grade traffic, we can help ensure your infrastructure is built for success.
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
📱 WhatsApp: +8801911119966
🌐 Website: www.vos3000.com
🌐 Blog: multahost.com/blog
📥 Downloads: VOS3000 Downloads
VOS3000 caller number pool configuration for CLI rotation on outbound calls. Setup random and poll…
VOS3000 protect route configuration guide for smart backup gateway activation. Learn how timer-based failover with…
VOS3000 outbound registration setup guide for carrier SIP trunk connections. Configure VOS3000 to register outbound…
VOS3000 SIP debug guide with Wireshark capture, log analysis, and tcpdump commands. Learn essential troubleshooting…
Evite perdidas por saldo negativo VOS3000: configure Anti Overdraft, limite de descubierto (limitMoney) y bloqueo…
Configuracion inicial VOS3000 despues de instalar: agregar primer proveedor, crear cuenta SIP, tabla de tarifas…