This module provides db api interface to redis database
<!-- 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 -->
- [ ] Commit message has the format required by CONTRIBUTING guide
- [ ] Commits are split per component (core, individual modules, libs, utils, ...)
- [ ] Each component has a single commit (if not, squash them into one commit)
- [ ] 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)
- [ ] 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
- [ ] 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/1422
-- Commit Summary --
* Modules: db_redis for usrloc module
-- File Changes --
A src/modules/db_redis/Makefile (36)
A src/modules/db_redis/README (89)
A src/modules/db_redis/db_redis.c (100)
A src/modules/db_redis/doc/Makefile (4)
A src/modules/db_redis/doc/db_redis.xml (45)
A src/modules/db_redis/doc/db_redis_admin.xml (86)
A src/modules/db_redis/redisdb_base.c (1189)
A src/modules/db_redis/redisdb_connection.c (100)
A src/modules/db_redis/redisdb_connection.h (43)
A src/modules/db_redis/redisdb_dbase.h (96)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1422.patchhttps://github.com/kamailio/kamailio/pull/1422.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/1422
### 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
Kamailio takes care of sending in-dialog keep-alives using OPTIONS when dlg_set_attribute ka-src and ka-dst is used. It also sends OPTIONS to correct address if a client sends Re-Invite indicating a network change, which is a common case with mobile clients (switching between mobile-data and Wifi) fixed in #273
The problem is that it ends the dialog on missing even one keep-alive response. Missing a response is possible when the client is handling the network change and keep-alive is sent around that time.
Thus, having a configurable counter after which you expect to end the dialog might be helpful. For eg. you decide to end the dialog after we miss 3 responses for keep-alives in a row.
Something like dlg_set_attribute(ka-src, 3) where 3 indicates the number of responses that can be missed before ending the dialog.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/438
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests.
If you have questions about using Kamailio or related to its configuration file,
ask on sr-users mailing list:
* http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing
C code, ask on sr-dev mailing list
* http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the
developers to troubleshoot the issue.
If you submit a feature request (or enhancement), you can delete the text of
the template and only add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
(paste your output here)
```
--
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/1137
Hello all,
It seems there has been a regression between kamailio 5.1.0 and 5.1.1 with the topos module.
### Description
Kamailio acts as a proxy for asterisk instances residing in a private IP range and other entities (subscribers, peers) residing on other networks. This is a multihomed installation, with 4 interfaces total (but mhomed is set to no).
Just by upgrading to 5.1.1, topos will complain with:
`tps_storage_record(): no local address - do record routing for all initial requests`
for re-INVITEs within an established dialog. This warning is also printed for other in-dialog requests (BYE, ACK).
Also common behaviour with all those in-dialog requests is that if the request received by kamailio had a Contact header, topos will strip it before relaying (true for re-INVITE and ACK).
For ACK there seem to be no obvious side-effects, because there's no response to it. For BYE, its 200 OK response is routed properly, in contrast with the 200 OK to the re-INVITE.
During the processing of 200 OK to re-INVITE, the following relevant lines are printed in the logs:
```
DEBUG: topos [tps_msg.c:1031]: tps_response_sent(): handling outgoing response
DEBUG: topos [tps_msg.c:1038]: tps_response_sent(): no x-branch header - nothing to do
```
During the processing of 200 OK to BYE, the following relevant lines are printed in the logs:
```
DEBUG: topos [tps_msg.c:1031]: tps_response_sent(): handling outgoing response
DEBUG: topos [tps_msg.c:376]: tps_pack_message(): compacted headers - x_via1: [SIP/2.0/UDP 192.168.1.1:5060;rport=5060;received=2.2.2.2;branch=z9hG4bK-c1a29abe](86) - x_via2: [](0) - x_vbranch1: [z9hG4bK-c1a29abe](16)
DEBUG: topos [tps_msg.c:485]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [](0) - s_rr: [](0)
DEBUG: topos [tps_msg.c:490]: tps_pack_message(): compacted headers - as_contact: [](0) - bs_contact: [](0)
DEBUG: topos [tps_storage.c:124]: tps_storage_lock_get(): tps lock get: 436
```
### Troubleshooting
Downgrading to 5.1.0 fixes the issue, with no changes in configuration.
#### Reproduction
Most SIP logic adheres to the sample configuration file, one difference being that record_route() is performed regardless of request method, as required for topos (although to reproduce this issue this change is not needed, as record_route() is performed for INVITEs anyway with the sample configuration file).
To reproduce on my setup, I initiate a call which kamailio will forward to asterisk, making sure topos is loaded. I then put the call on hold to generate a re-INVITE and watch as a) outgoing INVITE lacks a Contact header and b) Final reply to re-INVITE won't be routed, instead causing several retransmissions from asterisk.
#### SIP Traffic
I'm not sure SIP Traffic is relevant here, as only the Contact header missing is what strikes me as most odd. I can share pcaps and logs privately if needed.
### Additional Information
* **Kamailio Version**
Kamailio 5.1.1 on debian stretch from sipwise's repo
* **Operating System**:
```
Debian 9.1
```
* **Other pertinent configuration information**:
* The following issues might be relevant: #1356, #1350
* This kamailio box has several network interfaces. mhomed is not used, instead force_send_socket is called where necessary.
--
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/1421