CDRtool vs CGRATES for Opensips 2.2 +

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

CDRtool vs CGRATES for Opensips 2.2 +

Jeff Wilkie
Just pinging the general community on a pros/cons list between these two systems for rating calls.  I would love to hear feedback on comparisons and experiences. Finding it hard to see big differences from documentation other than methods to produce the records and the graphical front end. 

Thanks

Jeff Wilkie


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: CDRtool vs CGRATES for Opensips 2.2 +

DanB
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


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: CDRtool vs CGRATES for Opensips 2.2 +

Annus Fictus
+1

Thank you

El 05/03/2017 a las 06:32, DanB escribió:

> 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
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: CDRtool vs CGRATES for Opensips 2.2 +

Jeff Wilkie
In reply to this post by DanB
DanB,

Thanks for the very useful information!

I'm reading that the preferred install OS for CGRATES is Debian.  Most of our development happens on CENTOS 6.x.  Are there packages yet for CENT?  Or would we be required to install from source if we keep that OS?

Thanks

Jeff Wilkie


On Sun, Mar 5, 2017 at 6:32 AM, DanB <[hidden email]> wrote:
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


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: CDRtool vs CGRATES for Opensips 2.2 +

DanB
In reply to this post by Jeff Wilkie

Hi Jeff,


You can build packages for CentOS also, you can find more details here:

https://github.com/cgrates/cgrates/tree/master/packages

On the other hand, in order to avoid abusing OpenSIPS mailing list with CGRateS related questions, feel free to join our google group or IRC channel and come up with any additional questions.

Cheers,
DanB


On 08.03.2017 10:26, [hidden email] wrote:
Message: 1
Date: Tue, 7 Mar 2017 17:26:40 -0500
From: Jeff Wilkie [hidden email]
To: OpenSIPS users mailling list [hidden email]
Subject: Re: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 +
Message-ID:
	[hidden email]
Content-Type: text/plain; charset="utf-8"

DanB,

Thanks for the very useful information!

I'm reading that the preferred install OS for CGRATES is Debian.  Most of
our development happens on CENTOS 6.x.  Are there packages yet for CENT?
Or would we be required to install from source if we keep that OS?

Thanks

Jeff Wilkie


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users