CDRs is a standalone subsystem within CGRateS responsible to process CDR events. It is accessed via CGRateS RPC APIs or separate HTTP handlers configured within http section inside JSON configuration.
- Due to multiple interfaces exposed, the CDRs is designed to function as centralized server for CDRs received from various sources. Examples of such sources are:
- *real-time events from interfaces like Diameter, Radius, Asterisk, FreeSWITCH, Kamailio, OpenSIPS * *files* like .csv, .fwv, .xml, .json. * *database events* like sql, kafka, rabbitmq.
CDRs is configured within cdrs section from JSON configuration via the following parameters:
- Will enable starting of the service. Possible values: <true|false>.
- Select extra fields from the request, other than the primary ones used by CGRateS (see storage schemas for listing those). Used in particular applications where the received fields are not selectable at the source(ie. FreeSWITCH JSON).
- Controls storing of the received CDR within the StorDB. Possible values: <true|false>.
- In case of decoupling the events charging from CDRs, the charges done by SessionS will be stored in sessions_costs StorDB table. When receiving the CDR, these costs will be retrieved and attached to the CDR. To avoid concurrency between events and CDRs, it is possible to configure a multiple number of retries from StorDB table.
- Connections towards ChargerS component to query charges for CDR events. Empty to disable the functionality.
- Connections towards RALs component to query costs for CDR events. Empty to disable the functionality.
- Connections towards AttributeS component to alter information within CDR events. Empty to disable the functionality.
- Connections towards ThresholdS component to monitor and react to information within CDR events. Empty to disable the functionality.
- Connections towards StatS component to compute stat metrics for CDR events. Empty to disable the functionality.
- List of CDRe profiles which will be processed for each CDR event. Empty to disable online CDR exports.
Receives the CDR in the form of CGRateS Event together with processing flags attached. Activating of the flags will trigger specific processing mechanisms for the CDR. Missing of the flags will be interpreted based on defaults. The following flags are available, based on the processing order:
- Will process the event with AttributeS. This allows modification of content in early stages of processing(ie: add new fields, modify or remove others). Defaults to true if there are connections towards AttributeS within JSON configuration.
- Will process the event with ChargerS. This allows forking of the event into multiples. Defaults to true if there are connections towards ChargerS within JSON configuration.
- Will perform a refund for the CostDetails field in the event. Defaults to false.
- Will calculate the Cost for the event using the RALs. If the event is *prepaid the Cost will be attempted to be retrieved out of event or from sessions_costs table in the StorDB and if these two steps fail, RALs will be queried in the end. Defaults to false.
- Will re-rate the CDR as per the *rals flag, doing also an automatic refund in case of *prepaid, *postpaid and *pseudoprepaid request types. Defaults to false.
- Will store the CDR to StorDB. Defaults to store_cdrs parameter within JSON configuration. If store process fails for one of the CDRs, an automated refund is performed for all derived.
- Will export the event matching export profiles. These profiles are defined within cdre section inside JSON configuration. Defaults to true if there is at least one online_cdr_exports profile configured within JSON configuration.
- Will process the event with the ThresholdS, allowing us to execute actions based on filters set for matching profiles. Defaults to true if there are connections towards ThresholdS within JSON configuration.
- Will process the event with the StatS, allowing us to compute metrics based on the matching StatQueues. Defaults to true if there are connections towards StatS within JSON configuration.
- Classic rating of your CDRs.
- Rating queues where one can receive the rated CDR few milliseconds after the CommSwitch has issued it. With custom export profiles there can be given the feeling that the CommSwitch itself sends rated CDRs.
- Rating with derived charging where we calculate automatically the cost for the same CDR multiple times (ie: supplier/customer, customer/distributor or local/premium/mobile charges).
- Fraud detection on CDR Costs with profiling.
- Improve network transparency based on monitoring Cost, ASR, ACD, PDD out of CDRs.