<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
See comments in this PR, https://github.com/kamailio/kamailio/pull/1437
new features are now implemented in the module `acc_json`
#### Load tested
```
Total 1000000 INVITE calls sent in 2294479 ms at rate of 435/sec
Total 1000000 responses received in 2295273 ms at rate of 435/sec:
Detailed responses received:
- 200 responses: 1000000 (OK)
------
TOTAL responses: 1000000 (rate=435/sec)
```
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1440
-- Commit Summary --
* acc_json: adding module
-- File Changes --
M src/Makefile.groups (2)
A src/modules/acc_json/Makefile (29)
A src/modules/acc_json/acc_json_mod.c (279)
A src/modules/acc_json/acc_json_mod.h (42)
A src/modules/acc_json/doc/Makefile (4)
A src/modules/acc_json/doc/acc_json.xml (42)
A src/modules/acc_json/doc/acc_json_admin.xml (299)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1440.patchhttps://github.com/kamailio/kamailio/pull/1440.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/1440
…he cluster
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [X ] Commit message has the format required by CONTRIBUTING guide
- [X] Commits are split per component (core, individual modules, libs, utils, ...)
- [X] Each component has a single commit (if not, squash them into one commit)
- [X] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [X] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [X ] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1444
-- Commit Summary --
* ndb_redis: fix check on server name len when adding a new server to the cluster
-- File Changes --
M src/modules/ndb_redis/redis_client.c (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1444.patchhttps://github.com/kamailio/kamailio/pull/1444.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/1444
### Description
<!--
Have a problem with cnxcc call monitoring.
__set_max_credit() allocates new call as expected:
"DEBUG: cnxcc [cnxcc_mod.c:444]: __dialog_created_callback(): Flag is not
set for this message. Ignoring
DEBUG: cnxcc [cnxcc_mod.c:1569]: __set_max_credit(): Setting up new call
for client [2], max-credit[0.100000], cost-per-sec[0.010000], initial-pulse
[6], final-pulse [6],
call-id[2f77fd103d0bfa28718d896876b373fe at b2b.user.agent:50600]
DEBUG: cnxcc [cnxcc_mod.c:1470]: set_ctrl_flag(): Flag set!
DEBUG: cnxcc [cnxcc_redis.c:313]: redis_get_int(): Got INT value:
concurrent_calls=0i
DEBUG: cnxcc [cnxcc_redis.c:68]: redis_get_or_create_credit_data():
credit_data with ID=[2] DOES NOT exist in the cluster, creating it...
DEBUG: cnxcc [cnxcc_redis.c:92]: redis_insert_credit_data(): Inserting
credit_data_t using ID [2]
DEBUG: cnxcc [cnxcc_mod.c:1125]: __get_or_create_credit_data_entry():
Credit entry didn't exist. Allocated new entry [0x7f17668f6d70]
DEBUG: cnxcc [cnxcc_mod.c:1255]: __alloc_new_call_by_money(): New call
allocated for client [2]".
So that I can see values inside redis:
redis.youwillnever.find:6389> HGETALL cnxcc:money:2
1) "concurrent_calls"
2) "0"
3) "consumed_amount"
4) "0.000000"
5) "ended_calls_consumed_amount"
6) "0.000000"
7) "max_amount"
8) "0.000000"
9) "number_of_calls"
10) "1"
11) "type"
12) "1"
But cnxcc doesn't update credit amount during the call.
modparam("debugger", "mod_level", "cnxcc=4") but there are no rows in
kamailio log like:
"DEBUG: cnxcc [cnxcc_check.c:94]: check_calls_by_money(): ec=0.000000,
ca=0.600000, ca2=0.600000
DEBUG: cnxcc [cnxcc_check.c:107]: check_calls_by_money(): Client
[some_client] | Ended-Calls-Credit-Spent: 0.000000 TotalCredit/MaxCredit:
0.600000/3.000000".
cnxcc parameters:
modparam("cnxcc", "dlg_flag", FLG_DLG)
modparam("cnxcc", "redis", "addr=redis.youwillnever.find;port=6389;db=0")
modparam("cnxcc", "credit_check_period", 1)
function that performs credit setup:
if
(!cnxcc_set_max_credit("$var(setid)","$var(credit)","$var(cost_per_sec)","$var(i_pulse)","$var(f_pulse)"))
{
xlog("L_WARN", "----- cnxcc: $fU - Error setting up credit
control - R=$ru ID=$ci\n");
sl_send_reply("402", "Payment Required");
}
Why is it so? And as see, all values are set zero. Seems to be problem with
redis inserts.
Any ideas are highly appreciated. Thanks.
-->
### Troubleshooting
#### Reproduction
<!--
-
-->
#### Debugging Data
<!--
-
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
-
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
-
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
-
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.0.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 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 on 17:22:52 Nov 27 2017 with gcc 5.4.0
```
* **Operating System**:
<!--
-
-->
```
Debian stretch
Linux machine_name_here SMP Tue Dec 5 10:49:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1387
This is a snip from the user's mailing list, I'm just adding it to the issue tracker, as it is yet to be confirmed as a bug, only here for tracking pruporses:
```
I have a situation where I have 2 devices registering with the same AOR, I have the registrar module's max_contacts parameter set to 1 and I use the 0x04 flag on the save function.
When I use dmq_usrloc for replication, I can see 2 contacts registered for the AOR on the "client" nodes whereas the node where the actual registration took place only has 1 contact for the AOR.
```
```
It seems to me like another bug, although again I'm not familiar with the module so can't be sure without looking that it is not intended behaviour.
I plan to look later this week when I have some time but in the meantime, you can send me the examples directly if you like.
```
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/265
I reproduced in a lab with 3 Kamailio servers
```
kamailio_first 127.0.0.101
modparam("dmq", "server_address", "sip:127.0.0.101:5060")
modparam("dmq", "notification_address", "sip:127.0.0.103:5060")
modparam("dmq", "multi_notify", 1)
modparam("dmq", "num_workers", 2)
modparam("dmq", "ping_interval", 15)
kamailio_second 127.0.0.102 notification_peer: 127.0.0.103
modparam("dmq", "server_address", "sip:127.0.0.102:5060")
modparam("dmq", "notification_address", "sip:127.0.0.103:5060")
modparam("dmq", "multi_notify", 1)
modparam("dmq", "num_workers", 2)
modparam("dmq", "ping_interval", 15)
kamailio_third 127.0.0.103 notification_peer: 127.0.0.101
modparam("dmq", "server_address", "sip:127.0.0.103:5060")
modparam("dmq", "notification_address", "sip:127.0.0.101:5060")
modparam("dmq", "multi_notify", 1)
modparam("dmq", "num_workers", 2)
modparam("dmq", "ping_interval", 15)
```
` kamcmd -s /var/run/kamailio_$1/kamailio_ctl dmq.list_nodes | grep -e host -e status -e last -e local | tr '\n' ' ' | sed -e 's/host/\n&/g'`
```
show dmq bus: first
host: 127.0.0.102 status: 2 last_notification: 0 local: 0
host: 127.0.0.103 status: 2 last_notification: 0 local: 0
host: 127.0.0.101 status: 2 last_notification: 0 local: 1
show dmq bus: second
host: 127.0.0.101 status: 2 last_notification: 0 local: 0
host: 127.0.0.103 status: 2 last_notification: 0 local: 0
host: 127.0.0.102 status: 2 last_notification: 0 local: 1
show dmq bus: third
host: 127.0.0.102 status: 2 last_notification: 0 local: 0
host: 127.0.0.101 status: 2 last_notification: 0 local: 0
host: 127.0.0.103 status: 2 last_notification: 0 local: 1
```
```
/etc/init.d/kamailio_first stop
/etc/init.d/kamailio_third stop
/etc/init.d/kamailio_third start
/etc/init.d/kamailio_first start
```
` kamcmd -s /var/run/kamailio_$1/kamailio_ctl dmq.list_nodes | grep -e host -e status -e last -e local | tr '\n' ' ' | sed -e 's/host/\n&/g'`
```
show dmq bus: first
host: 127.0.0.103 status: 2 last_notification: 0 local: 0
host: 127.0.0.101 status: 2 last_notification: 0 local: 1
show dmq bus: second
host: 127.0.0.101 status: 8 last_notification: 0 local: 0
host: 127.0.0.103 status: 8 last_notification: 0 local: 0
host: 127.0.0.102 status: 2 last_notification: 0 local: 1
show dmq bus: third
host: 127.0.0.101 status: 2 last_notification: 0 local: 0
host: 127.0.0.103 status: 2 last_notification: 0 local: 1
```
The bus will remain broken, I think there is a second scenario that can break.
The notes I took when I found this (I consider this was a limitation not a bug)
Why : when Kamailio_third is shutting down, it will send a message to every peers telling them he is now inactive so they will not try to contact him again.
once restarted no nodes will contact him because they have an inactive state for him, at this point the only way he can learn about the other nodes is by contacting Kamailio_first, however Kamailio_first will not know about the other nodes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1349