In case you weren’t sure how CGRateS can be used, I’ve outlined a couple of typical use cases.
Real-time Call rating with credit control
This is possibly the most common use-case. Real time call rating enables prepaid services, reduces credit risk, and can also support real-time capabilities such as fraud detection, revenue assurance, least-cost routing.
To enable real-time rating you need a switch or router in the path of the call setup that supports this. Of course, most VoIP service providers will be using other open-source tools like Kamailio, Asterisk, Asterisk, or OpenSIPs which can be configured to support real-time rating. Other products may be able to support this too, and CGRateS has various APIs that can be used to integrate with these, including a Diameter Credit-control interface.
Despite CGRateS supporting multiple interfaces for integration, the basic concept of real-time rating is the same in each case:
- A call attempt is made to the switch/router
- The switch/router asks CGRateS to authorise the call based on the call parameters and subscriber’s credit balance
- CGRates calculates the call rate based on the call parameters (typically the dialled destination) and compares this to the subscriber’s balance
- CGRateS returns a yes or no response to the switch/router depending on the balance status and subscriber configuration
- The switch/router then allows or disallows the call to be completed
In the case of voice/video calls or other long session-based services, it’s impossible to know in advance how long the call will last. In this case the process above is repeated multiple times for the duration of the call with, in each case, authorisation requested for a portion of the call, for instance, 1 minute. CGRateS will, effectively, reserve credit from the subscriber’s account for this period. This means the subscriber could run out of credit during the middle of the call and, in this case, the call will be terminated. If the subscriber terminates the call, then any unused credit that has been reserved is returned to the subscriber’s account.
A similar scenario can be used for data charging, with data units (e.g. 1 Mb) being reserved instead of call duration.
This type of real-time rating is based on CGRateS maintaining accounts and credit balances for each subscriber.
Also note that the call authentication is purely based on call cost and credit balance. It is not a call authentication as no subscriber credentials are involved. Credential based authentication is something that would normally be handled by the switch/router.
CGRateS also records the call details and can output CDRs for reporting, call logging or to be processed by a billing system.
Real-time Call rating without credit control
There are scenarios where it is desirable to perform a real-time rating to support, for example, real-time fraud detection, but where it is not necessary or possible to support credit control. In this case, call usage is streamed in real-time to CGRateS from the switch/router, where it is rated. However, in this case there is no feedback to the switch/router, so there is no way to deny the call attempt or to cut off the call if the subscriber runs out of credit.
This works simply be streaming the CDRs to CGRateS in real-time as they are produced. Note that in most cases, CDRs are not produced until the call ends, although many systems will produce intermediate CDRs during long-duration calls.
CGRateS has the ability to stream the rated CDRs onwards, such as to an offline billing system.
This is a more traditional model of rating where CDRs are gathered and then submitted for rating in bulk. From CGRateS perspective, this is really no different from rating in real time. The main difference is in the external implementation which requires a tool to push the CDRs to CGRateS from the store.
As before, CGRateS can maintain and debit individual accounts, or can output rated CDRs for another system to process.
The scenarios I’ve outlined here are all based on voice calling. CGRateS can equally handle rating for just about any other type of service you can think of including usage-based data services, and event billing (such as for SMS).
These work similarly. For instance, for data services, instead of reserving and rating time, you would normally rate data usage in Megabytes. For event services, the unit of reservation simply becomes a single item (e.g. a single SMS).