### Description
We are trying to use CNXCC in order to monitor credit usage but it doesn't appear to be working. The cnxcc_set_max_credit call appears to be working partially as we can see that a new key is created in the Redis DB but with all the values set to 0. The values that we set in the cnxcc_set_max_credit are hardcoded but it doesn't seem to work. This is an example of what we find in the Redis DB: ``` 1637599472.872820 [1 127.0.0.1:53578] "HEXISTS" "cnxcc:money:pippo@dom.domain.it" "concurrent_calls" 1637599472.872942 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70" 1637599472.873043 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "concurrent_calls" "0" 1637599472.873159 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70" 1637599472.873292 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "consumed_amount" "0.000000" 1637599472.873404 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70" 1637599472.873515 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "ended_calls_consumed_amount" "0.000000" 1637599472.873634 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70" 1637599472.873752 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "max_amount" "0.000000" 1637599472.873875 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70" 1637599472.874000 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "number_of_calls" "0" 1637599472.874115 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70" 1637599472.874269 [1 127.0.0.1:53578] "HSET" "cnxcc:money:pippo@dom.domain.it" "type" "1" 1637599472.874381 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70" 1637599472.874481 [1 127.0.0.1:53578] "SREM" "cnxcc:kill_list:money" ""pippo@dom.domain.it"" 1637599472.874585 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70" 1637599472.874747 [1 127.0.0.1:53578] "HINCRBY" "cnxcc:money:pippo@dom.domain.it" "number_of_calls" "1" 1637599472.874845 [1 127.0.0.1:53578] "EXPIRE" "cnxcc:money:pippo@dom.domain.it" "70" ```
This issue is identical to the one described in #1387
### Troubleshooting
#### Reproduction
We are running Kamailio 5.5 from the official repos on Debian 10. All the modules are installed through the repo. This is the config that we are currently using to set the values for the modules. We also tried setting the values straight into the function bypassing the variables but the result is the same. ``` $dlg_var(credit) = "50.0"; $var(connect_cost) = "5.0"; $var(cost_per_sec) = "1.0"; $var(i_pulse) = 1; $var(f_pulse) = 1; xlog("$dlg_var(label) $var(credit) $var(connect_cost) ");
if (cnxcc_set_max_credit("$dlg_var(label)", "$dlg_var(credit)", "$var(connect_cost)", "$var(cost_per_sec)", "$var(i_pulse) ", "$var(f_pulse)") < 0) { xlog("Failed to setup credit control"); sl_send_reply("503", "Internal Server Error"); exit; } ``` #### Log Messages
The call to cnxcc_set_max_credit() doesn't throw any errors and returns 1 as if everything worked correctly
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` version: kamailio 5.5.2 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 8.3.0 ```
* **Operating System**:
``` No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster
Linux kamailio 5.11.22-5-pve #1 SMP PVE 5.11.22-10 (Tue, 28 Sep 2021 08:15:41 +0200) x86_64 GNU/Linux ```
Likely there is no active developer focusing on cnxcc. Maybe you can try to run with debug=3 and see if you can spot any hint in the debug messages.
This is what we see in the debug log regarding CNXCC:
``` Nov 24 10:26:25 kamailio /usr/sbin/kamailio[37945]: DEBUG: {1 2334 INVITE c70a26ae946c48ac9e7043b303d1f573} cnxcc [cnxcc_mod.c:1539]: ki_set_max_credit(): Setting up new call for client [ae4b751c3@sip.domain.it], max-credit[50.000000], connect-cost[5.000000], cost-per-sec[1.000000], initial-pulse [1], final-pulse [1], call-id[c70a26ae946c48ac9e7043b303d1f573] Nov 24 10:26:25 kamailio /usr/sbin/kamailio[37945]: DEBUG: {1 2334 INVITE c70a26ae946c48ac9e7043b303d1f573} cnxcc [cnxcc_mod.c:1470]: set_ctrl_flag(): Flag set! Nov 24 10:26:25 kamailio /usr/sbin/kamailio[37945]: DEBUG: {1 2334 INVITE c70a26ae946c48ac9e7043b303d1f573} cnxcc [cnxcc_redis.c:364]: redis_get_int(): Got INT value: concurrent_calls=0i Nov 24 10:26:25 kamailio /usr/sbin/kamailio[37945]: DEBUG: {1 2334 INVITE c70a26ae946c48ac9e7043b303d1f573} cnxcc [cnxcc_redis.c:69]: redis_get_or_create_credit_data(): credit_data with ID=[ae4b751c3@sip.domain.it] DOES NOT exist in the cluster, creating it... Nov 24 10:26:25 kamailio /usr/sbin/kamailio[37945]: DEBUG: {1 2334 INVITE c70a26ae946c48ac9e7043b303d1f573} cnxcc [cnxcc_redis.c:105]: redis_insert_credit_data(): Inserting credit_data_t using ID [ae4b751c3@sip.domain.it] Nov 24 10:26:25 kamailio /usr/sbin/kamailio[37945]: DEBUG: {1 2334 INVITE c70a26ae946c48ac9e7043b303d1f573} cnxcc [cnxcc_mod.c:1148]: __get_or_create_credit_data_entry(): Credit entry didn't exist. Allocated new entry [0x7f9442efd448] Nov 24 10:26:25 kamailio /usr/sbin/kamailio[37945]: DEBUG: {1 2334 INVITE c70a26ae946c48ac9e7043b303d1f573} cnxcc [cnxcc_mod.c:1265]: __alloc_new_call_by_money(): New call allocated for client [ae4b751c3@sip.domain.it] ```
The values reported by the function appear to be right but then in the Redis DB everything is set to 0.
Is there any other modules that is able to disconnect active calls and block new ones based on a credit limit? We found some alternatives but they all depend on external software that would complicate implementing the solution.
There are the ims_ocs and ims_charging modules, that could be used for such a system. But this is also not really a "plug and play" solution. If you find some issue with the code, we always welcome pull requests.
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #2948 as not planned.