sr-dev November 2021

sr-dev@lists.kamailio.org

20 participants
312 discussions

[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 … [View More]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 [View Less]

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. #… [View More]

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 … [View More]

2 2

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

14 Aug '22

<!-- Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for feature requests. If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list: * http://lists.kamailio.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.kamailio.org/cgi-bin/mailman/listinfo/sr-dev … [View More]

4 10

[kamailio/kamailio] kamctl - maintenance for dbtextdb.py tool (#2469)
by Daniel-Constantin Mierla 24 Jun '22

24 Jun '22

**kamctl** include a python tool that is parsing SQL statements to do operations over the **db_text** files, for the common db operations (e.g., insert, delete). It is located at: * https://github.com/kamailio/kamailio/tree/master/utils/kamctl/dbtextdb The tool was contributed long time ago and not kept up to date, being known not to work with Python3 (e.g., #2464). This issue is created to see if someone has the interest to pick up the maintenance of this tool, if not it will be removed … [View More]

3 5

[kamailio/kamailio] [kamctl] Dispatcher operations in a case of db_text are mostly incorrect (#2464)
by Igor Olhovskiy 24 Jun '22

24 Jun '22

### Description On creating dispatcher with `kamctl` in the case of `db_text` it fails ### Troubleshooting #### Reproduction Point `kamctlrc` to DB_TEXT. Run `kamctl dispatcher add 1 sip:asterisk_2:5060 1 3` Run 'kamctl dispatcher add 1 sip:asterisk_2:5060 1 3 'prefix=123' 'test1'' Run 'kamctl dispatcher show' Run 'kamctl dispatcher reload' #### Debugging Data ``` # kamctl dispatcher add 1 sip:asterisk_2:5060 1 3 attrs cannot be empty or null -e \E[37;31mERROR: dispatcher - SQL Error ```… [View More] ``` # kamctl dispatcher add 1 sip:asterisk_2:5060 1 3 'prefix=123' 'test1' Traceback (most recent call last): File "/usr/lib/x86_64-linux-gnu/kamailio//kamctl/dbtextdb/dbtextdb.py", line 1243, in <module> main(sys.argv) File "/usr/lib/x86_64-linux-gnu/kamailio//kamctl/dbtextdb/dbtextdb.py", line 1230, in main dataset = conn.Execute(' '.join(argv[1:])) File "/usr/lib/x86_64-linux-gnu/kamailio//kamctl/dbtextdb/dbtextdb.py", line 423, in Execute self.WriteTempTable() File "/usr/lib/x86_64-linux-gnu/kamailio//kamctl/dbtextdb/dbtextdb.py", line 1138, in WriteTempTable self.temp_file.write(header.strip() + '\n') File "/usr/lib/python3.7/tempfile.py", line 620, in func_wrapper return func(*args, **kwargs) TypeError: a bytes-like object is required, not 'str' -e \E[37;31mERROR: dispatcher - SQL Error ``` dump is showing active dispatchers, show - is not. ``` # kamctl dispatcher dump { "jsonrpc": "2.0", "result": { "NRSETS": 1, "RECORDS": [{ "SET": { "ID": 1, "TARGETS": [{ "DEST": { "URI": "sip:asterisk_2:5060", "FLAGS": "AP", "PRIORITY": 0 } }] } }] }, "id": 124 } root@e529c8cb4f62:/# kamctl dispatcher show -e dispatcher gateways ``` No result on reload ``` # kamctl dispatcher reload { "jsonrpc": "2.0", "result": { }, "id": 160 } ``` ### Possible Solutions I've tried to add data to the table manually, but here I got another issue. But on Kamailio load, the only first dispatcher is processed. Will add another issue on this. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` /# kamailio -v version: kamailio 5.4.1 (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_BLACKLIST, 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**: Debian 10/Docker ``` # uname -a Linux 9b7efa852274 5.3.18-lp152.36-default #1 SMP Tue Aug 18 17:09:44 UTC 2020 (885251f) 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/2464 [View Less]

3 4

[kamailio/kamailio] crash related to functions in cfg file parser for invalid cfg (#2239)
by Henning Westerholt 14 Jun '22

14 Jun '22

Against current git master. ``` henning@static:~/repositories/kamailio$ cat etc/crash-4.cfg #!KAMAILIO loadmodule "sl.so" request_route { switch (1) { case -1: send_reply("404", "Not Found"); case -2: send_reply("405",("Method Not Allowed"); exit; } ``` > $ ./src/kamailio -f etc/crash-4.cfg -L src/modules/ -Y /tmp -E -d > 0(2278) CRITICAL: <core> [core/cfg.y:3549]: yyerror_at(): … [View More]

2 2

[kamailio/kamailio] [Feature Request] Add reload capability for geoip2 module (#2029)
by Joel Serrano 13 Apr '22

13 Apr '22

### Description Currently, the `geoip2` module loads the IP database at startup and keeps it in cache and there is no way to tell Kamailio to reload the database without a full restart. ### Possible Solutions To keep this module inline with other modules that use external datasources, I would suggest to implement a new RPC command and a new geoip2 function to reload the database defined in the `path` geoip2 modparam without the need of a restart. I'm not aware of the effort required for … [View More]

2 3

[kamailio/kamailio] Kamailio 5.4.x dialog profiles functionality dead-lock on certain high-load scenarios (Issue #2923)
by Henning Westerholt 30 Mar '22

30 Mar '22

### Description The Kamailio 5.4.x dialog profiles functionality can lead to dead-lock on certain high-load scenarios. The Kamailio dialog profiles are used to track parallel channels for about 200 outgoing PSTN carrier interconnections. During high traffic times (like several thousands parallel calls) the Kamailio server will frequently (e.g. hourly) goes into an end-less loop while executing get_profile_size in the configuration script. This causes the locking for the dialog profiles never … [View More]be released and Kamailio will stop serving traffic. Internal monitoring tools and RPC commands stay working, as long as they do not touch the dialog functionality. A similar (dedicated) Kamailio setup is used for tracking parallel channels for customers. Here the dead-lock is not observed that frequently, but aparentely also some crashes happens in a much longer time interval. ### Troubleshooting After analysis of the back-traces with GDB the get_profile_size() function was removed from the configuration script. After this change the crash did not happened anymore for several days. #### Reproduction Issue could not be reproduced so far. #### Debugging Data ##### bt 1 (some data removed) (gdb) bt \# 0 0x00007f57cf3b00da in get_profile_size (profile=0x7f50ccbc7e80, value=0x7ffd9928f300) at dlg_profile.c:859 n = 364 i = 12 ph = 0x7f50d3e4b7d0 \# 1 0x00007f57cf419c67 in w_get_profile_size_helper (msg=0x7f57d699d418, profile=0x7f50ccbc7e80, value=0x7ffd9928f300, spd=0x7f57d6916960) at dialog.c:941 \# 2 0x00007f57cf41a459 in w_get_profile_size3 (msg=0x7f57d699d418, profile=0x7f50ccbc7e80, value=0x7f57d6935118, result=0x7f57d6916960) at dialog.c:982 \# 3 0x0000000000463fea in do_action (h=0x7ffd99293610, a=0x7f57d6936488, msg=0x7f57d699d418) at core/action.c:1094 \# 4 0x00000000004711ee in run_actions (h=0x7ffd99293610, a=0x7f57d6936488, msg=0x7f57d699d418) at core/action.c:1581 \# 5 0x000000000046058b in do_action (h=0x7ffd99293610, a=0x7f57d690fda8, msg=0x7f57d699d418) at core/action.c:700 The first back-trace was taking from a running process with gdb. The counter in f0 does not increased that much during this time, probably due the overflow of the loop counter. ##### bt2 (analysis with data structure with gdb scripts) Here the loop counter in f0 showed a really high value. Expected size of dialog profiles hash table: (gdb) p profile->entries[3] $4 = {first = 0x7f9bfd4aad98, content = 2068} (gdb) p profile->entries[7] $3 = {first = 0x7f9c12079f70, content = 784} (gdb) p profile->entries[12] $6 = {first = 0x7f9c02be5d50, content = 7600} (gdb) p profile->entries[14] $2 = {first = 0x7f9bff636de8, content = 6764} hash table bucket 14 shows a lot of corruption and the loop never ends (carrier names and IPs replaced). The list for hash bucket 7 got linked to the list for hash bucket 14: counter 6755: prev 0x7f9c0b9dcde0 - current 0x7f9c02e5b378 - next 0x7f9c0a5f9ba0 - value carrier1-XX.XX - hash 14 counter 6756: prev 0x7f9c02e5b378 - current 0x7f9c0a5f9ba0 - next 0x7f9c0860b968 - value carrier1-XX.XX▒▒▒▒ - hash 14 counter 6757: prev 0x7f9c0a5f9ba0 - current 0x7f9c0860b968 - next 0x7f9bfe3f3a78 - value carrier1-XX.XX▒▒▒▒ - hash 14 counter 6758: prev 0x7f9c0860b968 - current 0x7f9bfe3f3a78 - next 0x7f9c10d977f0 - value carrier1-XX.XX - hash 14 counter 6759: prev 0x7f9bfe3f3a78 - current 0x7f9c10d977f0 - next 0x7f9c0ae198b0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 6760: prev 0x7f9c10d977f0 - current 0x7f9c0ae198b0 - next 0x7f9c12079f70 - value carrier3-XX.XX - hash 7 counter 6761: prev 0x7f9c0ae198b0 - current 0x7f9c12079f70 - next 0x7f9c011f2540 - value-carrier2-XX.XX▒▒▒▒ - hash 7 counter 6762: prev 0x7f9c12079f70 - current 0x7f9c011f2540 - next 0x7f9bfff886f0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 6763: prev 0x7f9c011f2540 - current 0x7f9bfff886f0 - next 0x7f9c05db00a8 - value carrier3-XX.XX= - hash 7 [...] counter 28270: prev 0x7f9c019d06e8 - current 0x7f9bfaf18290 - next 0x7f9c12c90680 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 28271: prev 0x7f9bfaf18290 - current 0x7f9c12c90680 - next 0x7f9c086a2b58 - value-carrier2-XX.XX▒▒▒▒ - hash 7 counter 28272: prev 0x7f9c12c90680 - current 0x7f9c086a2b58 - next 0x7f9c0b4f09e8 - value carrier2-XX.XX▒▒▒▒ - hash 7 [...] hash table bucket 7 is still consistent regarding the loop, but already shows initial sign of corruption. There is one item of the list for hash bucket 14 visible: counter 780: prev 0x7f9c0db57ac8 - current 0x7f9c02225700 - next 0x7f9bfbf7db08 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 781: prev 0x7f9c02225700 - current 0x7f9bfbf7db08 - next 0x7f9c10d977f0 - value carrier1-XX.XX- hash 14 counter 782: prev 0x7f9bfe3f3a78 - current 0x7f9c10d977f0 - next 0x7f9c0ae198b0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 783: prev 0x7f9c10d977f0 - current 0x7f9c0ae198b0 - next 0x7f9c12079f70 - value carrier3-XX.XX - hash 7 total size of hash table is 784 #### Log Messages No special log messages observed. #### SIP Traffic SIP traffic looked ok during analysis of the core dumps. ### Possible Solutions * adding additional safe-guards for the get_profile_size function to not access data from other hash buckets * stopping the loop counter after some threshold * finding and fixing the source of the internal data corruption (obviously) * refactoring the dialog modules to use another approach for storing the dialog profile information ### Additional Information * **Kamailio version**: Kamailio 5.4.7, compiled from git repository * **Operating System**: CentOS 7.9 -- 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/2923 [View Less]

3 6

← Newer
1
...
5
6
7
8
9
10
11
...
32
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev November 2021