Your customer does not care if Asterisk, AGI, MySQL or the datacenter failed. He only knows the call did not complete.
Most providers do not wake up planning to buy high availability. They buy it after the first serious outage, after the first traffic spike, or after a customer proves the platform became more important than the architecture behind it.
Mark what is true in your operation
This is not a technical quiz. It is a business risk check. If several statements are true, your customer base has already outgrown a single-server call path.
One Asterisk server still handles most of my production calls.If that server is busy, unstable or offline, the business feels it immediately.
SIP Proxy receives the call first and sends it to weighted slave Asterisk servers, so production traffic is not tied to one machine. You can add new slaves when traffic grows or set a slave weight to 0 to remove it from production without changing the customer proxy address.
If my main Asterisk fails, calls do not automatically continue on another server.A backup that depends on manual action is recovery, not high availability.
SIP Proxy dispatcher can send traffic to another available slave when one slave is down or overloaded. This also lets you remove a slave temporarily by setting weight to 0 for maintenance, troubleshooting or capacity control.
Every call still depends on AGI execution.AGI is useful, but at scale every extra process and delay becomes part of your capacity limit.
app_mbilling runs as a native C application inside Asterisk, reducing AGI overhead in the live call path. Because the slave role is lighter, many deployments can use modest hardware such as 2 CPU cores and 4 GB RAM.
My slaves need the master database online to keep processing calls.This is simple, but it can turn the master DB into the point that stops everything.
A slave can read replicated local tables for call authorization, while CDR import updates the master when connectivity returns.
I have customers who would complain after a few minutes without calls.When customers depend on your platform, downtime becomes a commercial problem, not only a technical one.
Proxy plus slave capacity reduces the chance that one server incident becomes a customer-visible outage. It also lets you prepare capacity before the next large customer arrives.
I want to use more than one datacenter, region or group of servers.That requires traffic distribution, weights, and a clean way to assign proxies to slaves.
Each proxy can be assigned to specific slave groups, making it easier to separate regions, datacenters or customer traffic. You can dedicate slaves to a high-traffic callcenter and keep it separated from common customers.
I want one MagnusBilling panel, but many call-processing servers.Centralized billing with distributed Asterisk processing is exactly where the C Application fits.
MagnusBilling remains the master panel while app_mbilling on slaves handles the call processing locally. You can keep one central panel while adding or removing call-processing servers as needed.
A bad hour of traffic would cost more than USD 40.The license is small compared to the cost of a serious interruption.
At USD 40 per server, the app is cheaper than accepting repeated interruption risk for paid traffic. The lower hardware requirement also helps you scale with more small slaves instead of one expensive server.
The moment this becomes obvious is usually too late
Customers do not ask how elegant your architecture is. They ask why calls failed, why balance was not updated, why failover was manual, and why you did not prepare before selling them production traffic.
What changes with the C Application
Without it
- AGI remains in the live call path for every decision.
- Scaling often means bigger servers, not a better architecture.
- Failover depends on manual work or improvised scripts.
- The master database can become the dependency that stops slaves.
- Adding more Asterisk servers increases operational complexity.
With it
- Call processing runs inside Asterisk through a native C module.
- SIP Proxy can distribute calls to slave servers using weights.
- Specific proxies can use specific groups of slaves.
- Slaves can read local replicated tables when that model is preferred.
- MagnusBilling remains the central panel while calls are processed across servers.
Operational advantages you feel after installation
The C Application is not only about surviving a failure. It changes how you operate, scale and troubleshoot MagnusBilling every day.
With SIP Proxy and weighted slaves, you can add capacity when new customers arrive or traffic grows. You can also remove a slave from production by setting its weight to 0, without changing the customer-facing proxy address.
Instead of waiting for one server to reach the limit, you keep the architecture ready. New slave servers can be prepared and added to the proxy pool as the business grows.
Because call processing runs in native C and the slave role is lighter, many deployments can use small slave servers. A 2-core CPU with 4 GB RAM can be enough for a slave server in this architecture.
When one customer has a difficult issue, you can stop sending normal traffic to a slave by setting weight to 0, point only that customer to the slave, and analyze calls without noise from all other clients.
A high-traffic callcenter does not need to share the same call-processing servers used by common customers. You can isolate that customer on specific slaves and keep the rest of the platform cleaner.
You keep MagnusBilling centralized while the actual call processing is distributed. This gives you more control without turning every new Asterisk server into a separate billing system.
Common reasons people delay, and the honest answer
Information and conditions before you buy
The first part of this page helps you understand why you need the C Application. This part explains exactly what you are buying, how the architecture works, and the commercial conditions.
The monthly payment is for the right to use the MagnusBilling C Application on each server where it is installed. The price is USD 40 per month, per server.
Installation/configuration of the C Application requires SSH root access to the server because the native Asterisk module must be installed and compiled in the Asterisk environment.
The monthly C Application payment does not include support, troubleshooting, training, custom work, emergency help or operational assistance. Support requires a separate commercial support contract.
Support is not provided partially, casually, or on demand without the proper commercial support contract. There are no exceptions.
If you have commercial support, requests must be clear and specific. Ask one task or topic at a time so the support can be handled efficiently.
MagnusBilling is open source. The monthly payment is not for MagnusBilling itself; it is exclusively for using the C Application addon.
Database and CDR architecture options
This model is simpler and balances are updated immediately, but it is recommended mainly when servers are in the same datacenter or have very stable connectivity. If the master database is offline, slaves can stop processing calls.
This model lets slaves keep reading local data and continue processing calls when the master is temporarily unavailable. It is useful for different datacenters, regions or countries.
The C Application call path is read-oriented. CDRs are imported later on the master, and the balance is discounted when those CDRs are processed.
If slaves use a local database and the master stays offline for too long, calls may continue while CDRs are waiting to be imported. When the master returns, balances are updated and prepaid customers can become negative.
Proxy, slaves and scaling rules
SIP Proxy can distribute calls to slaves using weight. Stronger servers can receive more calls, smaller servers can receive less.
You can prepare new slaves and add them to the proxy pool as traffic grows. You can also set a slave weight to 0 to stop sending normal traffic to that slave without changing the customer's proxy address.
A proxy can be configured to use specific slaves. This allows separated structures while still keeping one centralized MagnusBilling panel.
High-traffic customers, such as callcenters, can be isolated on dedicated slaves instead of being mixed with common customers.
For troubleshooting, set a slave weight to 0, send only the affected customer to that slave, and analyze calls without noise from other clients.
Because app_mbilling is native C and the slave role is lighter, many slave servers can run with modest hardware, such as 2 CPU cores and 4 GB RAM.
If you marked 3 or more risks, this is not a future upgrade. It is your next infrastructure step.
You do not buy the C Application because it is written in C. You buy it because your MagnusBilling is already important enough that calls should not depend on one fragile path.