Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
Rating the data
144 views
Skip to first unread message
Domen Kosmač
Apr 3, 2025, 6:56:29 AMApr 3
to CGRateS
Hey,
so I've managed to rate my calls and texts, but having problems with rating the data usage.
I've provided the zip with all the setup files, now when I run it with the cgr-loader, it doesnt import some csvs. To do that I use the script files to invoke the API with the remaining files (chargers/actionTriggers). Now after that is done I ran the load the plans etc. with:
After that I ran the accounts_insert script to add the one account.
So with the setup complete, I then test the voice and sms with these requests:
Voice:
SMS:
Then I check the balance and it changes accordingly.
When I try to do the data CDR:
I've tried with different destinations aswell, but to no awail. I keep getting it rated as 0 and I can't figure one. In some different setups I managed to get it rated, but it never gets substracted from the plan values. I would also like to rate it as MBs.
Thank you and best regards,
Domen
so I've managed to rate my calls and texts, but having problems with rating the data usage.
I've provided the zip with all the setup files, now when I run it with the cgr-loader, it doesnt import some csvs. To do that I use the script files to invoke the API with the remaining files (chargers/actionTriggers). Now after that is done I ran the load the plans etc. with:
{
"id": 6,
"method": "APIerSv1.LoadTariffPlanFromStorDb",
"params": [
{
"TPid": "softnet-mobil",
"DryRun": false,
"Validate": true
}
]
}
After that I ran the accounts_insert script to add the one account.
So with the setup complete, I then test the voice and sms with these requests:
Voice:
{
"method": "CDRsV1.ProcessCDR",
"params": [
{
"ToR": "*voice",
"Tenant": "softnet-mobil",
"OriginID": "test1",
"Source": "*sessions",
"RequestType": "*postpaid",
"Account": "38612345678",
"Category": "slo-voice",
"Subject": "38612345678",
"Destination": "3861",
"SetupTime": "2024-02-08T13:01:53.668+01:00",
"AnswerTime": "2024-02-08T13:01:53.668+01:00",
"Usage": 1000000000
}
]
}
SMS:
{
"method": "CDRsV1.ProcessCDR",
"params": [
{
"ToR": "*generic",
"Tenant": "softnet-mobil",
"OriginID": "test2",
"Source": "*sessions",
"RequestType": "*postpaid",
"Account": "38612345678",
"Category": "slo-sms-mms",
"Subject": "38612345678",
"Destination": "3861",
"SetupTime": "2024-02-08T13:01:53.668+01:00",
"AnswerTime": "2024-02-08T13:01:53.668+01:00",
"Usage": 10
}
]
}
Then I check the balance and it changes accordingly.
When I try to do the data CDR:
{
"method": "CDRsV1.ProcessCDR",
"params": [
{
"ToR": "*data",
"Tenant": "softnet-mobil",
"OriginID": "test3",
"Source": "*sessions",
"RequestType": "*postpaid",
"Account": "38612345678",
"Category": "slo-data",
"Subject": "38612345678",
"Destination": "3861",
"SetupTime": "2024-02-08T13:01:53.668+01:00",
"AnswerTime": "2024-02-08T13:01:53.668+01:00",
"Usage": 1073741824
}
]
}
I've tried with different destinations aswell, but to no awail. I keep getting it rated as 0 and I can't figure one. In some different setups I managed to get it rated, but it never gets substracted from the plan values. I would also like to rate it as MBs.
Thank you and best regards,
Domen
Armir Veliaj
Apr 4, 2025, 8:37:36 AMApr 4
to CGRateS
Hi Domen,
After checking your configurations and csv files, I noticed that you have added an extra field, 'Directions[6]', in your Actions.csv file. Please note that the fields in your Actions.csv should always match the structure provided as in the sample here: https://github.com/cgrates/cgrates/blob/master/data/tariffplans/tutorial/Actions.csv
Additionally, please send us the cgr-engine logs and the ngrep output for further checking.
Thanks,
Armir
After checking your configurations and csv files, I noticed that you have added an extra field, 'Directions[6]', in your Actions.csv file. Please note that the fields in your Actions.csv should always match the structure provided as in the sample here: https://github.com/cgrates/cgrates/blob/master/data/tariffplans/tutorial/Actions.csv
Additionally, please send us the cgr-engine logs and the ngrep output for further checking.
Thanks,
Armir
Domen Kosmač
Apr 5, 2025, 12:57:48 PMApr 5
to CGRateS
Hey Amir,
I appologize from the comment line being confusing, I've used the newer version setup so when I count and check the values of the fields they are matching the one from the tutorial you've linked. The cgr-logs show everything is working, as the CDRs are processed, but not deducted from the plans values.
I couldn't find any other logs that would indicate any errors or something being wrong.
Best regards,
Domen
I appologize from the comment line being confusing, I've used the newer version setup so when I count and check the values of the fields they are matching the one from the tutorial you've linked. The cgr-logs show everything is working, as the CDRs are processed, but not deducted from the plans values.
I couldn't find any other logs that would indicate any errors or something being wrong.
Best regards,
Domen
petek, 4. april 2025 ob 14:37:36 UTC+2 je oseba armir....@itsyscom.com napisala:
Domen Kosmač
Apr 7, 2025, 3:59:02 AMApr 7
to CGRateS
Here are the ngrep logs:
T source_ip -> my_server_ip:2080 [AP] #17
POST /jsonrpc HTTP/1.1.
Content-Type: application/json.
User-Agent: PostmanRuntime/7.43.3.
Accept: */*.
Postman-Token: 5f7f4a4d-dae9-4014-a756-cea3428258c2.
Host: my_server_ip :2080.
Accept-Encoding: gzip, deflate, br.
Connection: keep-alive.
Content-Length: 551.
.
{
"method": "CDRsV1.ProcessCDR",
"params": [
{
"ToR": "*data",
"Tenant": "softnet-mobil",
"OriginID": "test10",
"Source": "*sessions",
"RequestType": "*postpaid",
"Account": "38612345678",
"Category": "slo-data",
"Subject": "38612345678",
"Destination": "386",
"SetupTime": "2024-02-08T13:01:53.668+01:00",
"AnswerTime": "2024-02-08T13:01:53.668+01:00",
"Usage": 1073741824
}
]
}
###########exit
And cgr-engine logs:
Apr 07 09:56:10 mobile04 cgr-engine[1169262]: CGRateS <34c5403> [1169262]: error: <MAX_INCREMENTS_EXCEEDED with 1073741824>, when creating increments slice, TimeSpan: {"TimeStart":"2024-02-08T13:01:53.668+01:00","TimeEnd":"2024-02-08T13:01:54.741741824+01:00","Cost":0,"RateInterval":{"Timing":null,"Rating":{"ConnectFee":0,"RoundingMethod":"","RoundingDecimals":0,"MaxCost":0,"MaxCostStrategy":"","Rates":[{"GroupIntervalStart":0,"Value":0,"RateIncrement":1,"RateUnit":1}]},"Weight":0},"DurationIndex":0,"Increments":null,"RoundIncrement":null,"MatchedSubject":"9fd633e1-6b71-41fb-9cb5-131ebfe39547","MatchedPrefix":"386","MatchedDestId":"*any","RatingPlanId":"*none","CompressFactor":0}
T source_ip -> my_server_ip:2080 [AP] #17
POST /jsonrpc HTTP/1.1.
Content-Type: application/json.
User-Agent: PostmanRuntime/7.43.3.
Accept: */*.
Postman-Token: 5f7f4a4d-dae9-4014-a756-cea3428258c2.
Host: my_server_ip :2080.
Accept-Encoding: gzip, deflate, br.
Connection: keep-alive.
Content-Length: 551.
.
{
"method": "CDRsV1.ProcessCDR",
"params": [
{
"ToR": "*data",
"Tenant": "softnet-mobil",
"Source": "*sessions",
"RequestType": "*postpaid",
"Account": "38612345678",
"Category": "slo-data",
"Subject": "38612345678",
"SetupTime": "2024-02-08T13:01:53.668+01:00",
"AnswerTime": "2024-02-08T13:01:53.668+01:00",
"Usage": 1073741824
}
]
}
And cgr-engine logs:
Apr 07 09:56:10 mobile04 cgr-engine[1169262]: CGRateS <34c5403> [1169262]: error: <MAX_INCREMENTS_EXCEEDED with 1073741824>, when creating increments slice, TimeSpan: {"TimeStart":"2024-02-08T13:01:53.668+01:00","TimeEnd":"2024-02-08T13:01:54.741741824+01:00","Cost":0,"RateInterval":{"Timing":null,"Rating":{"ConnectFee":0,"RoundingMethod":"","RoundingDecimals":0,"MaxCost":0,"MaxCostStrategy":"","Rates":[{"GroupIntervalStart":0,"Value":0,"RateIncrement":1,"RateUnit":1}]},"Weight":0},"DurationIndex":0,"Increments":null,"RoundIncrement":null,"MatchedSubject":"9fd633e1-6b71-41fb-9cb5-131ebfe39547","MatchedPrefix":"386","MatchedDestId":"*any","RatingPlanId":"*none","CompressFactor":0}
I've rechecked the logs, and I can see it being problematic.
Best regards,
Domen
Domen
sobota, 5. april 2025 ob 18:57:48 UTC+2 je oseba Domen Kosmač napisala:
Armir Veliaj
Apr 8, 2025, 7:38:23 AMApr 8
to CGRateS
Hi Domen,
After checking your logs, the <MAX_INCREMENTS_EXCEEDED> error is happening because the usage you're sending is higher than the default max increments. This limit can be increased in the config, but doing so may lead to higher resource usage and is not recommended.
So, the best approach would be to rate by MBs instead of bytes, as you also preferred. To do that, we need to know where this data is coming from (Diameter or any other provider you're using), so we can adjust the conversion before the data reaches CGRateS.
Thanks,
Armir
After checking your logs, the <MAX_INCREMENTS_EXCEEDED> error is happening because the usage you're sending is higher than the default max increments. This limit can be increased in the config, but doing so may lead to higher resource usage and is not recommended.
So, the best approach would be to rate by MBs instead of bytes, as you also preferred. To do that, we need to know where this data is coming from (Diameter or any other provider you're using), so we can adjust the conversion before the data reaches CGRateS.
Thanks,
Armir
Domen Kosmač
Apr 8, 2025, 8:58:16 AMApr 8
to CGRateS
Hey Amir,
so after afew days, I've realized what the error means. So I've decided I want to rate by KB (that will be the smallest amount of data). In the setup I provided I rated by 1 unit for 0.071. Now the issue is, that my price per unit is defined for MBs. When the amount of data for example will be 1KB, the price will be 0.0000693 (0.071 / 1024) instead of the old MBs price.
My question is, should I just keep the price down to 0.0000693, or can I change something else so it will scale down the price to KBs from MBs.
This is just a test for now, so the data is not coming from anywhere.
BR,
Domen
so after afew days, I've realized what the error means. So I've decided I want to rate by KB (that will be the smallest amount of data). In the setup I provided I rated by 1 unit for 0.071. Now the issue is, that my price per unit is defined for MBs. When the amount of data for example will be 1KB, the price will be 0.0000693 (0.071 / 1024) instead of the old MBs price.
My question is, should I just keep the price down to 0.0000693, or can I change something else so it will scale down the price to KBs from MBs.
This is just a test for now, so the data is not coming from anywhere.
BR,
Domen
torek, 8. april 2025 ob 13:38:23 UTC+2 je oseba armir....@itsyscom.com napisala:
Domen Kosmač
Apr 9, 2025, 2:00:35 AMApr 9
to CGRateS
Now that I've changed the price it seems that it is too low, because it gets rated with 0. Is there another way I can rate this?
torek, 8. april 2025 ob 14:58:16 UTC+2 je oseba Domen Kosmač napisala:
Armir Veliaj
Apr 10, 2025, 9:12:06 AMApr 10
to CGRateS
Hi Domen,
To make it more clear on what you are trying to achieve, we need to know:
1.All your latest CSV files for that rating plan of data you want to charge
2.What type of unit in the Usage you expect to receive in your scenario
3.If you want to define the rates in KBs or MBs
Thanks,
Armir
To make it more clear on what you are trying to achieve, we need to know:
1.All your latest CSV files for that rating plan of data you want to charge
2.What type of unit in the Usage you expect to receive in your scenario
3.If you want to define the rates in KBs or MBs
Thanks,
Armir
Domen
Apr 10, 2025, 9:22:49 AMApr 10
to CGRateS
Hey Armir,
I've managed to solve my problems. I edited the StorDB table tp_rates field rate to support up to 8 decimals and now it started to rate. I decided to rate by KBs, and the price is much lover than for MBs.
Also would this change highly impact the performance in production env?
BR,
Domen
I've managed to solve my problems. I edited the StorDB table tp_rates field rate to support up to 8 decimals and now it started to rate. I decided to rate by KBs, and the price is much lover than for MBs.
Also would this change highly impact the performance in production env?
BR,
Domen
četrtek, 10. april 2025 ob 15:12:06 UTC+2 je oseba armir....@itsyscom.com napisala:
Armir Veliaj
Apr 11, 2025, 8:56:46 AMApr 11
to CGRateS
Hi Domen,
Regarding performance, CGRateS operates by charging each increment in the Usage. For example, if the Usage is in KBs and you set the increment per each single KB, it will cause more resources consumption than if you had defined the increment to round up to MBs. So, having higher increments can help in better performance too.
Thanks,
Armir
Regarding performance, CGRateS operates by charging each increment in the Usage. For example, if the Usage is in KBs and you set the increment per each single KB, it will cause more resources consumption than if you had defined the increment to round up to MBs. So, having higher increments can help in better performance too.
Thanks,
Armir
Domen
Apr 15, 2025, 5:28:13 AMApr 15
to CGRateS
Hey Armir,
With the solution I've described in previous messages, it does work, but I do get some rounding errors.
Here is a JSON of a rated data CDR:
"Destination": "386",
"SetupTime": "2024-02-08T13:01:53.668+01:00",
"AnswerTime": "2024-02-08T13:01:53.668+01:00",
"RateIncrement": 1,
"RateUnit": 1
}
]
},
Now while the price in the rates is correct, it is wrong everywhere else, so in Accounting, Rating. So where can I change the decimals to 8 for Accounting and Rating?
Best regards,
Domen
thank you for the explanation. Now the problem I'm facing with rounding to MBs is that if we say a user has a data session of a 8KB. In this case I cannot charge the 1MB price as this would overcharge the user.
Do you have any ideas how I can use the 1MB price but charge only the fraction of the price for 1KB.
This is currently my rate:
RT_SLO_DATA1,0,0.00004004,1,1,0This is currently my rate:
With the solution I've described in previous messages, it does work, but I do get some rounding errors.
Here is a JSON of a rated data CDR:
{
"CGRID": "1fbefee9cfb86926757519357e077fd6a21aef0f",
"RunID": "*default",
"OrderID": 16,
"OriginHost": "",
"Source": "*sessions",
"OriginID": "test16",
"ToR": "*data",
"RequestType": "*postpaid",
"Tenant": "softnet-mobil",
"Category": "slo-data",
"Account": "3861234568",
"Subject": " 3861234568 ",
"CGRID": "1fbefee9cfb86926757519357e077fd6a21aef0f",
"RunID": "*default",
"OrderID": 16,
"OriginHost": "",
"Source": "*sessions",
"OriginID": "test16",
"ToR": "*data",
"RequestType": "*postpaid",
"Tenant": "softnet-mobil",
"Category": "slo-data",
"Account": "3861234568",
"Subject": " 3861234568 ",
"Destination": "386",
"SetupTime": "2024-02-08T13:01:53.668+01:00",
"AnswerTime": "2024-02-08T13:01:53.668+01:00",
"Usage": 1024,
"ExtraFields": {},
"ExtraInfo": "",
"Partial": false,
"PreRated": false,
"CostSource": "*cdrs",
"Cost": 0.04096,
"CostDetails": {
"CGRID": "1fbefee9cfb86926757519357e077fd6a21aef0f",
"RunID": "*default",
"StartTime": "2024-02-08T13:01:53.668+01:00",
"Usage": 1024,
"Cost": 0.04096,
"Charges": [
{
"RatingID": "f7c1943",
"Increments": [
{
"Usage": 1,
"Cost": 0.00004,
"AccountingID": "e0a984b",
"CompressFactor": 1024
}
],
"CompressFactor": 1
}
],
"AccountSummary": {
"Tenant": "softnet-mobil",
"ID": "38631290546",
"BalanceSummaries": [
{
"UUID": "c3eb8f89-5d3d-4e12-881e-6647cba23c53",
"ID": "TEST-DATA-EU",
"Type": "*data",
"Initial": 0,
"Value": 0,
"Weight": 10,
"Disabled": false
}
},
{
"UUID": "1f6e700c-506c-451a-bd42-3e3925bf9579",
"ID": "*default",
"Type": "*monetary",
"Initial": -0.08204,
"Value": -0.123,
"Disabled": false
}
],
"AllowNegative": false,
"Disabled": false
},
"Rating": {
"f7c1943": {
"ConnectFee": 0,
"RoundingMethod": "*up",
"RoundingDecimals": 5,
"MaxCost": 0,
"MaxCostStrategy": "",
"TimingID": "732edd5",
"RatesID": "a5a7cdc",
"RatingFiltersID": "80b8bb6"
}
},
"Accounting": {
"e0a984b": {
"AccountID": "softnet-mobil:38631290546",
"BalanceUUID": "1f6e700c-506c-451a-bd42-3e3925bf9579",
"RatingID": "",
"Units": 0.00004,
"ExtraChargeID": ""
}
},
"RatingFilters": {
"80b8bb6": {
"DestinationID": "*any",
"DestinationPrefix": "*any",
"RatingPlanID": "RP_EU_DATA_PREMIUM_OVER_QUOTA",
"Subject": "*out:softnet-mobil:EU-data:*any"
}
},
"Rates": {
"a5a7cdc": [
{
"GroupIntervalStart": 0,
"Value": 0.00004004,
"ExtraFields": {},
"ExtraInfo": "",
"Partial": false,
"PreRated": false,
"CostSource": "*cdrs",
"Cost": 0.04096,
"CostDetails": {
"CGRID": "1fbefee9cfb86926757519357e077fd6a21aef0f",
"RunID": "*default",
"StartTime": "2024-02-08T13:01:53.668+01:00",
"Usage": 1024,
"Cost": 0.04096,
"Charges": [
{
"RatingID": "f7c1943",
"Increments": [
{
"Usage": 1,
"Cost": 0.00004,
"AccountingID": "e0a984b",
"CompressFactor": 1024
}
],
"CompressFactor": 1
}
],
"AccountSummary": {
"Tenant": "softnet-mobil",
"ID": "38631290546",
"BalanceSummaries": [
{
"UUID": "c3eb8f89-5d3d-4e12-881e-6647cba23c53",
"ID": "TEST-DATA-EU",
"Type": "*data",
"Initial": 0,
"Value": 0,
"Weight": 10,
"Disabled": false
}
},
{
"UUID": "1f6e700c-506c-451a-bd42-3e3925bf9579",
"ID": "*default",
"Type": "*monetary",
"Initial": -0.08204,
"Value": -0.123,
"Disabled": false
}
],
"AllowNegative": false,
"Disabled": false
},
"Rating": {
"f7c1943": {
"ConnectFee": 0,
"RoundingMethod": "*up",
"RoundingDecimals": 5,
"MaxCost": 0,
"MaxCostStrategy": "",
"TimingID": "732edd5",
"RatesID": "a5a7cdc",
"RatingFiltersID": "80b8bb6"
}
},
"Accounting": {
"e0a984b": {
"AccountID": "softnet-mobil:38631290546",
"BalanceUUID": "1f6e700c-506c-451a-bd42-3e3925bf9579",
"RatingID": "",
"Units": 0.00004,
"ExtraChargeID": ""
}
},
"RatingFilters": {
"80b8bb6": {
"DestinationID": "*any",
"DestinationPrefix": "*any",
"RatingPlanID": "RP_EU_DATA_PREMIUM_OVER_QUOTA",
"Subject": "*out:softnet-mobil:EU-data:*any"
}
},
"Rates": {
"a5a7cdc": [
{
"GroupIntervalStart": 0,
"Value": 0.00004004,
"RateIncrement": 1,
"RateUnit": 1
}
]
},
"Timings": {
"732edd5": {
"Years": [],
"Months": [],
"MonthDays": [],
"WeekDays": [],
"StartTime": "00:00:00"
}
}
}
"732edd5": {
"Years": [],
"Months": [],
"MonthDays": [],
"WeekDays": [],
"StartTime": "00:00:00"
}
}
}
Now while the price in the rates is correct, it is wrong everywhere else, so in Accounting, Rating. So where can I change the decimals to 8 for Accounting and Rating?
Best regards,
Domen
petek, 11. april 2025 ob 14:56:46 UTC+2 je oseba armir....@itsyscom.com napisala:
Armir Veliaj
Apr 15, 2025, 11:58:46 AMApr 15
to CGRateS
Hi Domen,
If there is a difference between RateUnit and RateIncrement in your rates, there will be a difference also in the price that you get per unit. This is caused by rounding.
The value you are having for "Cost": 0.04096, is not fully precise because in your config it is set to the default "rounding_decimals": 5, but you can increase it in the general section of json config for a more precise value. While RoundingDecimals in DestinationRates is just used to round in CDRs, not for the actual calculation of the costs.
Hope this helps,
Thanks,
Armir
If there is a difference between RateUnit and RateIncrement in your rates, there will be a difference also in the price that you get per unit. This is caused by rounding.
The value you are having for "Cost": 0.04096, is not fully precise because in your config it is set to the default "rounding_decimals": 5, but you can increase it in the general section of json config for a more precise value. While RoundingDecimals in DestinationRates is just used to round in CDRs, not for the actual calculation of the costs.
Hope this helps,
Thanks,
Armir
Domen
Apr 17, 2025, 9:33:58 AMApr 17
to CGRateS
Hi Armir,
I've completly missed it in the configuration file. With the update to 8 decimals it correctly rounds.
I guess this is it with the questions about rating data.
Thank you for your patience and help.
BR,
Domen
I've completly missed it in the configuration file. With the update to 8 decimals it correctly rounds.
I guess this is it with the questions about rating data.
Thank you for your patience and help.
BR,
Domen
torek, 15. april 2025 ob 17:58:46 UTC+2 je oseba armir....@itsyscom.com napisala:
Reply all
Reply to author
Forward
0 new messages