[OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 +

DanB danb.lists at gmail.com
Sun Mar 5 06:32:02 EST 2017


Hi Jeff,

Although it is a slippery ground, in order to have the question 
answered, I can claim having experience with both systems (we used to 
install CDRTool for customers and still have today installs running 
since like 8 years without issues).

CDRTool (CDR rating system):

     * Written in php, works closely with db (eg: relies on it's query 
speed with some caching for parts of the rates)

     * Mature implementation, not much development changing the code 
over the years (other than bug fixes).

     * Simple rating definition and implementation.

     * Web interface for rates management as well as CDRs.

     * Designed around rating CDRs and maintaining account balance.


CGRateS (OCS - online charging system):

     * Written in Go, caches almost all information in process, database 
agnostic (abstracts databases into interfaces), database speed does not 
influence the speed of calculations, built on micro-services with full 
asynchronous processing.

     * Still in Release Candidate when it comes to architecture, evolved 
a lot over the years, master should be always stable in terms of 
functionality since it runs in production environments (architecture 
part is not yet declared stable - you can expect it to still evolve).

     * Complex rating (rates voice calls, data streams, sms, etc) and 
accounting (unlimited number of balances/bundles and failover between 
them during a call).

     * API (JSON) driven management (full set) with no official web 
interface available yet.

     * Additional functionality: fraud detection with automatic 
mitigation (3 layers: accounts, CDR stats, resources usage), CDR logging 
with support for interim records, QoS LCR and LCR over bundels, 
real-time (complete in memory) call statistics with pattern monitoring 
and triggers/web hooks towards external systems, derive charging 
(session emulation - reseller/distributor scenarios, customer/supplier 
parallel calculations), performance optimized (one CGRateS instance 
should be able to handle 5k requests per second in terms of rating 
calculations), built-in high availability for Diameter setups.


So these being said, it is all about the need vs price (time investment) 
you are ready to pay for it by using one system or another (considering 
both systems are opensource and you can extend yourself in one way or 
another). If you don't have complex rating requirements nor the need of 
increased CPS, I trust CDRTool will do the job just fine since it did it 
for us over the years (you get the advantage as said of simple 
management and architecture stability, quick learning curve). CGRateS on 
the other hand should be there if you decide you need more 
functionality/speed and you are also ready to offer it more time and 
efforts.


I hope this helps someone!

DanB




More information about the Users mailing list