Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Limiting Concurrent Users

209 views
Skip to first unread message

M B

unread,
Apr 21, 2025, 12:35:07 PMApr 21
to CGRateS
Hi all,
I am sure this is really basic, but I can't seem to find an answer (despite searching). Two queries, but first a bit of background:

Opensips is the registrar and calls are routed through freeswitch. so auth happens at opensips, but call hangup needs ot happen at freeswitch.

1. Do I need to setup event_socket at freeswitch and freeswitch agent at cgrates. Or, hangup will happen via Opensips?
2. I am trying to limit concurrent calls, via Chargers.csv and Resources.csv. But get the following error at cgrates (and similar at Opensips):
T 2025/04/21 16:29:12.589561 172.31.6.253:2014 -> 172.31.38.9:49598 [AP] #53
{"id":1516918652,"result":null,"error":"CHARGERS_ERROR:SERVER_ERROR: SERVER_ERROR: inline parse error for string: \u003c*resources:CONCURRENT_CALLS\u003e"}

What is the correct variable to for concurrent calls please?

TIA.

Armir Veliaj

unread,
Apr 22, 2025, 8:59:05 AMApr 22
to CGRateS
Hello,

1. Yes, you need to set up event_socket to use real-time data.
Otherwise, if real-time is not needed, you can make use of CDRs instead.

2. Regarding the error you're having, it appears to be an inline parsing issue related to the Chargers.csv.

Please send us that file so we can take a look.

Thanks,
Armir

M B

unread,
Apr 22, 2025, 10:11:26 AMApr 22
to CGRateS
Thanks a lot Armir. I seem to have managed the chargers.csv error. For concurrent call and max call duration, I have tried various things, including the change to Resources.csv as below (with filters.csv updated to include the correct account):

cgrates.org,ResGroup1,FLTR_RES,2014-07-29T15:00:00Z,-1,1,,false,true,10,*none


I have also tried the following (Resources.csv) as follows:
*any,MAX_CALL_TIME,*string:~*req.Category:call,,10s,1,Maximum call duration reached,true,false,10,
*any,CONCURRENT_CALLS,*string:~*req.Category:call,,,1,Maximum concurrent calls limit reached,true,false,10,

Don't think either limits the concurrent calls or max call duration. Appreciate if you could point me at the tutorial or share what to do.

Thanks again.

Armir Veliaj

unread,
Apr 24, 2025, 4:59:33 AMApr 24
to CGRateS
Hello,

You can use ResourceS for putting limit on the concurrent calls, but in your file putting "*any" to the Tenant field is not correct so you may have to use your actual Tenant.
If you want to get into more depth about ResourceS subsystem, you can check our tutorial here: https://cgrates.readthedocs.io/en/latest/resources.html#id2

Regarding max call duration it depends on your scenario, in authorization you have to let FreeSWITCH, Kamailio or any other SIP Servers you may be using to take care of it, and if you are doing it real-time with prepaid mode, you can decide a max duration set in the general config of SessionS section, where in "default_usage" you can put any value as limit, in your case for *voice as you may want in your calls: https://github.com/cgrates/cgrates/blob/master/config/config_defaults.go#L667

Hope it helps,

Thanks,
Armir

M B

unread,
Apr 28, 2025, 11:25:34 AMApr 28
to CGRateS
Thanks Armir,
This seems to be working correctly. Any idea what changes are required at Opensips end? Does the tutorial Opensips script work to limit concurrent calls and/or duration?

Armir Veliaj

unread,
Apr 29, 2025, 6:05:14 AMApr 29
to CGRateS
Hello,

It isn't in any OpenSIPS tutorial but it's done automatically. If ResourceS are exhausted, it won't connect because CGRateS handles everything on the backside. So, you don't need to make any changes in OpenSIPS, as the ResourceS will give an error and the call simply won't connect.

Thanks,
Armir

M B

unread,
Apr 29, 2025, 7:48:58 AMApr 29
to CGRateS
Thanks Armir,

That's what I was thinking. But I've tried various methods, I keep getting this authorization, when I make another call:

T 2025/04/28 19:57:31.163042 172.31.38.9:55842 -> 172.31.6.253:2014 [AP] #5
{ "method": "SessionSv1.AuthorizeEventWithDigest", "id": 500807406, "params": [ { "ProcessStatQueues": true, "ProcessThresholds": true, "ReleaseResources": true, "AllocateResources": true, "AuthorizeResources": true, "GetRoutes": false, "GetAttributes": true, "GetMaxUsage": true, "Event": { "Source": "OpenSIPS", "OriginHost": "172.31.38.9", "RequestType": "prepaid", "OriginID": "29a85988-4f01-d773-97c1-e30d31962f93", "Account": "1000000063", "SetupTime": "1745870251", "Destination": "TheNumber" } } ] }
#
T 2025/04/28 19:57:31.169522 172.31.6.253:2014 -> 172.31.38.9:55842 [AP] #6
{"id":500807406,"result":{"AttributesDigest":"","ResourceAllocation":"ResGroup1","MaxUsage":30,"RoutesDigest":null,"Thresholds":"","StatQueues":null},"error":null}
####
T 2025/04/28 19:57:42.638442 172.31.38.9:55842 -> 172.31.6.253:2014 [AP] #10
{ "method": "SessionSv1.AuthorizeEventWithDigest", "id": 500807410, "params": [ { "ProcessStatQueues": true, "ProcessThresholds": true, "ReleaseResources": true, "AllocateResources": true, "AuthorizeResources": true, "GetRoutes": false, "GetAttributes": true, "GetMaxUsage": true, "Event": { "Source": "OpenSIPS", "OriginHost": "172.31.38.9", "RequestType": "prepaid", "OriginID": "ff2acc48-53fb-31c2-b535-1f919063709c", "Account": "1000000063", "SetupTime": "1745870262", "Destination": "TheNumber" } } ] }
#
T 2025/04/28 19:57:42.644840 172.31.6.253:2014 -> 172.31.38.9:55842 [AP] #11
{"id":500807410,"result":{"AttributesDigest":"","ResourceAllocation":"ResGroup1","MaxUsage":30,"RoutesDigest":null,"Thresholds":"","StatQueues":null},"error":null}

The following (and many other variations), I've tried:
ACT_BLOCK_CONCURRENT,deny,Reason:MaxUsage Exceeded,,,,,,,,,,,,,,10
cgrates.org,THD_CONCURRENT_LIMIT,lt:~resource.ResGroup1.Allocated:1,2023-10-01T00:00:00Z,-1,1,1s,false,10,ACT_BLOCK_CONCURRENT,false
cgrates.org,FLTR_RES,string,~req.Account,1000000063,2025-01-01T00:00:00Z
cgrates.org,ResGroup1,FLTR_RES,2023-10-01T00:00:00Z,-1,1,,true,true,10,none

Despite the 30s MaxUsage, calls don't disconnect at 30s.

Any thoughts? Appreciate the help.

Armir Veliaj

unread,
May 2, 2025, 8:46:01 AMMay 2
to CGRateS
Hello,

Based on your ngrep that you sent, it appears that the MaxUsage was correctly calculated and sent by CGRateS. By default, OpenSIPS should consider this and  terminate the call on its end by its own configuration.
Since the MaxUsage was already sent, no additional configuration is needed on the CGRateS side, and modifying ResourceS will have no effect.

Thanks,
Armir

HS

unread,
May 2, 2025, 9:56:14 AMMay 2
to cgr...@googlegroups.com
Thanks a lot. How about the authorization for the 2nd call (whilst in a call)? Concurrent limit doesnt seem to work either. 

--
You received this message because you are subscribed to a topic in the Google Groups "CGRateS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cgrates/Nb7lbP8viTw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cgrates+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cgrates/bcd17979-f05d-42ec-a495-a47f754a0467n%40googlegroups.com.

Armir Veliaj

unread,
May 5, 2025, 11:09:21 AMMay 5
to CGRateS
Hello,

In normal situations, using ResourceS for concurrency limit should work, but to investigate your case, please provide the following:

-the complete ngrep output (use *localhost connections between services in your config), especially including the Resources requests/replies
-the CGRateS version you are using and CGR-engine logs
-your json configuration file
-your updated csv files, including the one that you have modified for Resources.csv

Thanks,
Armir

M B

unread,
May 21, 2025, 9:50:18 AMMay 21
to CGRateS
Hi Armir,

Thanks a lot for the help, apologies for the delay - I wanted to ensure that I've covered all possibilities before I update you. Attached are the logs/config you wanted.

1. Link to ngrep output - https://pastebin.com/UZVKbSSP
2. CGRates details
 "active_memory": "8.8MiB",
 "cpu_time": "1.08s",
 "go_version": "go1.23.2",
 "goroutines": 83,
 "node_id": "9ef2489",
 "open_files": 52,
 "os_threads_in_use": 9,
 "pid": 72331,
 "resident_memory": "60.3MiB",
 "running_since": "Wed May 21 12:31:08 UTC 2025",
 "system_memory": "21.6MiB",
 "version": "CGR...@v0.11.0~dev-20250121183033-c171937c3d8e"

3. Link to config.json - https://pastebin.com/62VmGFRn
4. I've made a script to load account/users etc - here it is (maybe the sequence is incorrect): https://pastebin.com/FsdCQcX2

Thanks again.

M B

unread,
May 30, 2025, 8:29:19 AMMay 30
to CGRateS
Armir,

Wondering if you need any more information please?

Thanks.

Armir Veliaj

unread,
May 30, 2025, 2:41:31 PMMay 30
to CGRateS
Hello,

I was checking the data that you sent to reproduce your scenario, and after checking your ngrep logs, they do not show the ResourceS there. I assume it's because the Authorize/Allocate/ReleaseResources flags are missing from your SessionSv1 requests.
To send the events to ResourceS, the flags need to be populated and set to true. Please check in your SIP agent and try to update it either on the OpenSIPS or FreeSWITCH side for init/terminate. In case you are doing auth with OpenSIPS, it should look something like this:

# check auth with CGRateS
$cgr_opt(GetMaxUsage) = 1; # also retrieve the max usage
$cgr_opt(AuthorizeResources) = 1;
$cgr_opt(AllocateResources) = 1;
$cgr_opt(ReleaseResources) = 1;

Thanks,
Armir

M B

unread,
May 31, 2025, 5:41:01 AM (14 days ago) May 31
to CGRateS
Thanks Armir.

I had mis-copied this part of the Opensips config, required some minor tweaks afterwards. Everything is ok now! Appreciate the help.

M B

unread,
Jun 6, 2025, 5:41:16 AM (8 days ago) Jun 6
to CGRateS
Armir,
Sorry to bother you again. You mentioned that we can tweak the default_usage values to preset MaxUsage. Which works fine. I'm wondering if its possible to preset MaxUsage by destinations/number called pls?

Thanks.

M B

unread,
Jun 10, 2025, 3:17:33 AM (4 days ago) Jun 10
to CGRateS
Apologies, same topic. Possible to set MaxUsage for specific accounts also? If yes, via Resources?

TIA.

M B

unread,
8:50 AM (11 hours ago) 8:50 AM
to CGRateS
Hi Armir,

Appreciate an update please.

Thanks.
Reply all
Reply to author
Forward
0 new messages