C Application Monthly payment per server
Keep growth from becoming a single-server problem
When customers depend on your VoIP service, one busy or unavailable server can become a business problem. app_mbilling processes calls as a native C application inside Asterisk. Combined with SIP Proxy and slave servers, it lets you distribute call processing while keeping MagnusBilling as your central management and billing panel.
US$ 40.00 · Monthly payment per server
Why choose this service
Add call-processing servers as traffic and customers grow
Distribute traffic by weight and isolate customers on dedicated slaves
Is your operation ready for the next traffic spike?
Recognize the dependencies
Consider this architecture if one Asterisk handles most production calls, failover requires manual intervention, or your slaves depend on the master database being continuously available. Multiple datacenters and high-traffic customers are further reasons to review your call path.
Plan before an outage
Backups help recover a system. A properly configured proxy and slave architecture can route new calls to another available server. Availability still depends on the proxy, databases, connectivity and failover configuration; the module alone is not a guarantee of uninterrupted service.
How the architecture works
app_mbilling: native processing
The C application runs inside Asterisk and reduces the overhead of AGI execution in the live call path. MagnusBilling remains the central panel, while slave servers handle call processing.
SIP Proxy: weighted distribution
The proxy directs calls to slave servers using weights. Assign more traffic to stronger servers and less to smaller ones. Its dispatcher can route new calls to other available slaves when configured to handle failures or overload.
Slave servers: capacity on demand
Prepare and add slaves as traffic grows. Set a slave’s weight to 0 to stop assigning normal traffic without changing the customer-facing proxy address. Different proxies can use specific slave groups for regions, datacenters or customer groups.
What changes in your daily operation
Investigate one customer without the noise
Remove a slave from normal distribution with weight 0, direct only the affected customer to it, and investigate that customer’s calls separately.
Keep demanding customers separate
Dedicate slaves to a high-traffic callcenter or a customer with particular requirements while keeping other customers on their own processing pool.
Scale with smaller servers
The lighter slave role can make modest hardware practical. The original deployment guidance gives 2 CPU cores and 4 GB RAM as an example; actual capacity depends on traffic, codecs, transcoding and configuration and must be validated for your workload.
Choose the database model for your operation
Direct connection to the master
A simpler model, with immediate balance updates, suited mainly to servers in the same datacenter or with very stable connectivity. If the master database becomes unavailable, slaves may stop processing calls.
Local replicated database
Slaves read replicated local tables for authorization and can continue processing calls during temporary loss of connectivity to the master. This model can suit different datacenters, regions or countries.
CDR import and prepaid balances
With the local replicated model, CDRs are imported into the master later and balances are discounted when those records are processed. If the master is unavailable for too long, calls can continue before charges are posted and prepaid balances can become negative. Plan this exposure before choosing the model.
Exactly what you are purchasing
Monthly license per server
The displayed price is monthly, for each server on which the C Application is installed. The license is for the addon; MagnusBilling itself remains open source.
Installation requires SSH root access
The native module must be installed and compiled in the Asterisk environment. Installation and configuration require SSH root access to the server.
Support is a separate contract
The monthly license does not include troubleshooting, training, custom work, emergency assistance, configuration guidance or operational support. These require a separate commercial support contract; partial or ad hoc support is not provided without that contract.
Clear requests for support customers
When using a commercial support contract, send one clear task or topic at a time so the team can address it efficiently.
SEE THE SERVICE IN ACTION
Watch the architecture video ↗What is included and what to know
Monthly license per server. Requires SSH root access for installation. Support, configuration assistance and troubleshooting require a separate support contract. With local database replication, delayed CDR imports can allow prepaid balances to become negative.
Monthly payment per serverQuestions before you buy
Does the monthly price include support?
No. It licenses the C Application on one server. Support, training, emergency help and operational assistance require a separate commercial support contract.
Do I need to replace my central panel?
MagnusBilling remains the central panel. The architecture distributes call processing to slaves through SIP Proxy. Plan the database and failover model with the team.
From your order to delivery
- Choose this service and sign in or create your customer account.
- Review the scope, quantity and payment method before confirming your order.
- After payment confirmation, coordinate installation or your support session with the team.
C Application
Make this the next improvement to your operation.
Choose your service now, or talk to the team if you need to confirm the fit before ordering.
Prepare my call-processing architecture ↗
US$ 40.00 · Monthly payment per server