sr-dev April 2022

sr-dev@lists.kamailio.org

17 participants
286 discussions

[kamailio/kamailio] [presence] `active_watchers` entries not removed on timeout or expiration. (Issue #3074)
by Mike Moore 06 Sep '22

06 Sep '22

### Description  When handling a `PUBLISH` we call [handle_publish()](https://kamailio.org/docs/modules/5.5.x/modules/presence.… and `NOTIFY`s are sent to all of the corresponding `active_watchers` (as expected). However, when `NOTIFY`s timeout (`408`), we're seeing that the corresponding entries in the `active_watchers` table are _not_ being deleted as expected. Furthermore, we've noticed that `NOTIFY`s are being sent to `active_watchers` which are expired (i.e. `expires < UNIX_TIMESTAMP()`) and when we run `kamcmd presence.cleanup`, no expired entries are removed from the `active_watchers` table. We suspect that all of these things might be related--the common theme being that records aren't deleted when expected. ### Troubleshooting #### Reproduction  In our setup, we're using Kamailio as a "presence server" (via the [presence](https://kamailio.org/docs/modules/5.5.x/modules/presence.html), [presence_dialoginfo](https://kamailio.org/docs/modules/5.5.x/modules/presen…, and [presence_xml](https://kamailio.org/docs/modules/5.5.x/modules/presence_xml.… modules). We're using [`subs_db_mode`](https://kamailio.org/docs/modules/5.5.x/modules/presence.html#presence.p.subs_db_mode) `3` (DB-only scheme) and we have multiple Kamailio instances connected to a shared database (MySQL `8.0.27`). Everything seems to be working as expected. However, as we accumulated stale entries in the `active_watchers` table we're finding that we're wasting more and more time on sending `NOTIFY`s to black holes. We're generating a _lot_ of traffic and waiting for the timeouts to hit is causing memory issues and backups. Here are the relevant portions of our `kamailio.cfg` file: ``` # ----- presence params ----- modparam("presence", "db_table_lock_type", 0) # Disable locking; MySQL has issues with this is enabled. modparam("presence", "db_update_period", -1) # Disable synchronization. modparam("presence", "db_url", PRESENCE_DB_URL) modparam("presence", "expires_offset", 60) # Force the client to send an UPDATE before the old PUBLISH expires. modparam("presence", "max_expires", 1800) modparam("presence", "min_expires", 1700) modparam("presence", "publ_cache", 0) # Disable the PUBLISH cache since the database is shared. modparam("presence", "server_address", "sip:$CLUSTER_DOMAIN_NAME:5060") # This becomes the value of the Contact header. modparam("presence", "sip_uri_match", 1) # Use case insensitive URI matching. modparam("presence", "subs_db_mode", 3) # Database-only scheme; everything is stored in the database. modparam("presence", "notifier_processes", 0) # Caution! Under load a race condition can cause CSeq's to be reused. modparam("presence", "timeout_rm_subs", 1) # ----- presence_dialoginfo params ----- modparam("presence_dialoginfo", "force_single_dialog", 1) # Maybe not all phones support multiple "dialog" elements? modparam("presence_dialoginfo", "force_dummy_dialog", 1) # Maybe not all phones support a null body? # ----- presence_xml params ----- modparam("presence_xml", "db_url", PRESENCE_DB_URL) modparam("presence_xml", "force_active", 1) # Skip permission/XCAP checks. modparam("presence_xml", "force_dummy_presence", 1) # Default to a simple "open" status when presentity info is unavailable. # ... route[PRESENCE] { if (!is_method("PUBLISH|SUBSCRIBE")) { return; } if (!t_newtran()) { sl_reply_error(); exit; } if (is_method("PUBLISH")) { handle_publish(); t_release(); } else if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); } exit; } ``` #### SIP Traffic  Here's a somewhat sanitized example (the message seems OK to us; however, the `Subscription-State: terminated; reason=timeout` does make us wonder--do we as the sender _know_ that the client is terminated/timed-out?): ``` 2022/04/05 21:09:55.209846 10.21.3.12:5060 -> 10.31.0.226:6060 NOTIFY sip:SomeUser@192.168.86.24:54639;alias=123.21.125.232~54639~1 SIP/2.0 Via: SIP/2.0/UDP presence-w.staging.internal:5060;branch=z9hG4bK43ea.648a1952000000000000000000000000.0 To: <sip:SomeOtherUser@9bfadf66-a77b-6a69-25f3-02d96d4aa946>;tag=2607596073 From: <sip:SomeUser@9bfadf66-a77b-6a69-25f3-02d96d4aa946>;tag=69309ea83adcd977af8788878e9f31b3-42e32342 CSeq: 66 NOTIFY Call-ID: 0_2607659559(a)192.168.86.24 Route: <sip:10.31.0.226:6060;r2=on;lr;ftag=2607596073>, <sip:55.8.122.110;r2=on;lr;ftag=2607596073> Content-Length: 710 Max-Forwards: 70 Event: dialog Contact: <sip:presence-w.staging.internal:5060> Subscription-State: terminated;reason=timeout Content-Type: application/dialog-info+xml <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="66" state="full" entity="sip:SomeUser@9bfadf66-a77b-6a69-25f3-02d96d4aa946"> <dialog id="0_1364146118(a)192.168.1.244" call-id="0_1364146118(a)192.168.1.244" direction="initiator"> <state>confirmed</state> <remote> <identity>sip:4355558565@9bfadf66-a77b-6a69-25f3-02d96d4aa945:5060</identity> <target uri="sip:4355558565@9bfadf66-a77b-6a69-25f3-02d96d4aa946:5060"/> </remote> <local> <identity>sip:SomeUser@9bfadf66-a77b-6a69-25f3-02d96d4aa946:5060</identity> <target uri="sip:SomeUser@123.130.50.202:58872"/> </local> </dialog> </dialog-info> ``` ### Possible Solutions  We didn't see any functions in the `presence` module that we could call directly to clean things up. One thought we had was to manually run some database commands from `event_route[presence:notify-reply]` (or in a `reply_route`). We've noticed that once the problematic entries are manually removed from the database that we no longer attempt to send `NOTIFY`s to the defunct destinations. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.5.4 (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 10.2.1 ``` * **Operating System**:  ``` $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye $ uname -a Linux ip-10-21-3-12 5.10.0-13-cloud-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3074 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3074(a)github.com>

2 4

[kamailio/kamailio] Ability to reload location attributes at runtime (#2299)
by Sergiu Pojoga 26 Aug '22

26 Aug '22

### Description Looking for a mechanism to reload Location attributes at runtime. Having both registered and permanent Contacts under AoR, with Attributes from `usrloc` to be used for various routing decisions. This is about attributes of permanent Contacts. Registered ones have `xavp_contact` of `usrloc` to store attributes during registration. **Problem:** Only way to make it work is: 1. adding a permanent Contact using `rpc ul.add` 2. assigning attributes in DB `location_attr` per RUID (can't find an rpc function for attributes) 3. restart Kamailio modparam("usrloc", "db_mode", 1) modparam("usrloc", "db_load", 1) This however is far from ideal, having to restart Kamailio for every change in attributes of a Contact. ### Expected behavior #### Actual observed behavior #### 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.3.3 (x86_64/linux) 44ccb9 * **Operating System**:  ``` (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/2299

3 8

[kamailio/kamailio] dialog: not able to set the hangup_reason , when we hangup calls using xmlrpc. (#1737)
by Surendra Tiwari 26 Aug '22

26 Aug '22

### Description We are using xmlrpc to terminate the calls once customer balance reaches to zero. call got terminated but we will not be able to set the dialog variable related to hangup_reason. There should be a way during dlg.terminate_dlg xmlrpc request that if i mention the some parameter then it should set before sending bye to callee and caller.  ### 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` ``` root@ip-172-31-4-160:/etc/kamailio# kamailio -version version: kamailio 5.1.4 (x86_64/linux) 6ebfda flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 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: 6ebfda compiled on 11:48:26 Sep 7 2018 with gcc 4.8.4 ``` * **Operating System**:  ``` root@ip-172-31-4-160:/etc/kamailio# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty root@ip-172-31-4-160:/etc/kamailio# uname -a Linux ip-172-31-4-160 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27 10:45:36 UTC 2018 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/1737

2 5

[kamailio/kamailio] keep new features in a file in the repository (#668)
by Victor Seva 26 Aug '22

26 Aug '22

This will allow us to point https://www.kamailio.org/wiki/features/new-in-devel to the file and "force" developers to update that file with the new features when they are introduced in the repository Remaining developers to upgrade the wiki seems pointless and anyone can create a PR for changes --- 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/668

4 4

[kamailio/kamailio] kazoo: consuming of events fails if message has no body (#1837)
by mihovilkolaric 26 Aug '22

26 Aug '22

### Description Consuming messages without message body fails due to a JSON parsing error: ``` ERROR: kazoo [kz_json.c:287]: kz_json_parse(): Error parsing json: unexpected end of data ERROR: kazoo [kz_json.c:288]: kz_json_parse(): ERROR: kazoo [kz_amqp.c:2960]: kz_amqp_send_worker_event(): error parsing json body ``` This makes it unable to consume messages from RabbitMQ's event exchange plugin ( https://www.rabbitmq.com/event-exchange.html ), as the documentatin states: **"The message body is always blank."** ### Possible Solutions As a possible fix I tried following change in kz_amqp.c: ``` void kz_amqp_send_worker_event(kz_amqp_server_ptr server_ptr, amqp_envelope_t* envelope, kz_amqp_bind_ptr bind) { char buffer[100]; kz_amqp_cmd_ptr cmd = NULL; kz_amqp_consumer_delivery_ptr ptr = NULL; json_obj_ptr json_obj = NULL; json_object* JObj = NULL; str* message_id = NULL; int idx = envelope->channel-1; int worker = 0; int _kz_server_id = server_ptr->id; int msg_size = envelope->message.body.len; //begin of changes int routingkey_size = envelope->routing_key.len; if (msg_size == 0 && routingkey_size > 0 ) { char *routingkey_data = pkg_malloc(routingkey_size + 1); memset(routingkey_data, 0, routingkey_size + 1); memcpy(routingkey_data, (char*)envelope->routing_key.bytes, routingkey_size); LM_DBG("Message size: %d\n", msg_size); LM_DBG("Routing Key: %s\n", routingkey_data); char *pos = strchr(routingkey_data,'.'); while (pos){ *pos = '_'; pos = strchr(pos,'.'); } LM_DBG("New Routing Key: %s\n", routingkey_data); sprintf(buffer, "kazoo:%s", routingkey_data); if(kz_amqp_consumer_fire_event(buffer) != 0) { LM_ERR("kazoo:%s not found", routingkey_data); } pkg_free(routingkey_data); return; } char *json_data = pkg_malloc(msg_size + 1); if(!json_data) { LM_ERR("no more package memory available. needed %d\n", msg_size + 1); return; } char *json_data = pkg_malloc(msg_size + 1); //end of changes if(!json_data) { LM_ERR("no more package memory available. needed %d\n", msg_size + 1); return; } ``` The change is rather simple: If there is no message-body supplied, the event-route _kazoo:<binding_key>_ is called (after replacing any '.' with '_' in the routing_key). -- 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/1837

3 6

[kamailio/kamailio] dialog: set $rs when failed TCP send (#2867)
by sergey-safarov 26 Aug '22

26 Aug '22

### Description I use TCP transport to relay SIP messages. When Kamailio cannot connect to another server then Kamailio generates response `408 Request Timeout`. inside `event_route[dialog:failed]` route block I check error code `$rs` but this value is `null`. This happens because Kamailio does not able to relay SIP messages and is not able to receive responses. But `tm` module generates a response `408 Request Timeout` and will be fine to init `$rs` pseudo-variable using tm module response. ### Expected behavior `$rs` pseudo-variable contains `tm` module response when kamailio does not receive a response from another server. #### Actual observed behavior `$rs` pseudo-variable contains `null` value when kamailio does not receive a response from another server. To check you can use ``` event_route[dialog:failed] { $var(code_xxx) = $(rs{re.subst,/([0-9])[0-9]{2}/\1xx/}); xlog("L_INFO", "websocket|log|dialog failed $rs; $var(code_xxx)\n"); } ``` And relay SIP message to host that reachable. -- 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/2867

3 4

[kamailio/kamailio] dispatcher: socket atribute usage for initial OPTIONS (#2853)
by sergey-safarov 26 Aug '22

26 Aug '22

### Description I use TCP sockets to relay calls to backend servers. Also, I have enabled `tcp_reuse_port` and enabled `socket` attribute in dispatcher settings. INVITE messages to backend servers are now properly send from port 5060. ### Expected behavior For all messages are used the same TCP socket and same source port for all messages (including OPTIONS). #### Actual observed behavior But initial OPTIONS (before the first call send) uses a random source port. ### Additional Information * **Kamailio Version** - output of `kamailio -v` used current c503d2bd31a580138a67f1d4a265ccde5791d271 with small customization. * **Operating System**: aarch64 ``` [root@sbc-a0 ~]# cat /etc/os-release NAME="CentOS Linux" VERSION="8" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="8" PLATFORM_ID="platform:el8" PRETTY_NAME="CentOS Linux 8" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:8" HOME_URL="https://centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-8" CENTOS_MANTISBT_PROJECT_VERSION="8" ``` -- 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/2853

2 2

[kamailio/kamailio] dialog: set context iuid for CANCEL requests (PR #3096)
by descartin 26 Aug '22

26 Aug '22

set context iuid for CANCEL requests to let isflagset function return the right value in case a dialog flag was previously set on the call   #### Pre-Submission Checklist    - [ ] 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 - [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:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Using kamailio 5.4 version, we have seen that dlg_isflagset is not detecting a dialog flag set in the request route for the initial INVITE, when a CANCEL request arrives. We have applied this change to set the dialog context unique ide for this request. Since it's done on dlg_onreply, dlg_onroute and dlg_ontimeout functions. This way, dlg_get_by_iuid(&dctx->iuid) in the function ki_dlg_isflagset is not NULL and dialog flags are detected. Is this change correct? Or can it generate any kind of issues? thanks a lot and regards David You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3096 -- Commit Summary -- * dialog: set context iuid for CANCEL requests to let isflagset function return the right value in case a dialog flag was previously set on the call -- File Changes -- M src/modules/dialog/dlg_handlers.c (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3096.patch https://github.com/kamailio/kamailio/pull/3096.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3096 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3096(a)github.com>

3 6

[kamailio/kamailio] [stirshaken] add identity header in reply messages or to a separate variable (#2770)
by sergei lavrov 14 Aug '22

14 Aug '22

4 10

[kamailio/kamailio] secfilter: Wrong format on RPC response data (Issue #2992)
by Olle E. Johansson 12 Aug '22

12 Aug '22

secfilter RPC functions to get statistics use a console format to printing data, suitable for **kamcmd** but not for any RPC method. This should be converted to a machine-parsable data structure (much like dispatcher, usrloc and htable data dumps). -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2992 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/2992(a)github.com>

2 3

← Newer
1
...
6
7
8
9
10
11
12
...
29
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev April 2022