sr-dev July 2024

sr-dev@lists.kamailio.org

16 participants
214 discussions

[kamailio/kamailio] Build for el9 without legacy geoip (PR #3886)
by Oded Arbel 07 Oct '24

07 Oct '24

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] 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: - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #3592 #### Description The `kamailio-geoip` RPM sub package currently builds both the `geoip` module - based on [the old and out of support MaxMind GeoIP library](https://github.com/maxmind/geoip-api-c) - and the newer `geoip2` module - based on [the currently supported `libmaxminddb`](https://github.com/maxmind/libmaxminddb). The old GeoIP C library had its end of support date at May 2022 but for a while was still shipped for many distributions. At this point though, the EPEL repository that shipped the GeoIP library for RHEL-based operating systems, has removed it from their repositories for "Enterprise Linux 9": ![Screenshot_20240620_144233](https://github.com/kamailio/kamailio/assets/381782/bb1f2481-57f7-48af-b0f1-0ba1c14a3042) Therefor builds using the bundled spec file fail on EL9 installations. The suggested change is to add an RPM build option `--with geoip2` that when specified will build just the `geoip2` module for the `kamailio-geoip` RPM subpackage. This build option is not enabled by default, unless the build is running on a RHEL 9 based OS - in which case it is set as the default, because otherwise trivial builds break. To revert to the older behavior in RHEL 9 based OSs (and assuming you have the required unsupported library installed correctly) one will need to set both `--without geoip2 --with geoip`. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3886 -- Commit Summary -- * packaging: RPM build option to build just the geoip2 module * packaging: make 'with geoip2' the default behavior for EL9 -- File Changes -- M pkg/kamailio/obs/kamailio.spec (36) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3886.patch https://github.com/kamailio/kamailio/pull/3886.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3886 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3886(a)github.com>

6 22

[kamailio/kamailio] IMS DB: Adding i-cscf database/tables under utils/kamctl/mysql (orig. from misc/examples/ims/icscf.sql) (PR #3876)
by markusmonka 03 Oct '24

03 Oct '24

4 8

[kamailio/kamailio] The tm.cancel function does not generate a “tm:local-request” event. (Issue #3831)
by JuanPascual2 30 Sep '24

30 Sep '24

Hello The tm.t_uac_start function generates a “tm:local-request” event. But the tm.cancel function doesn't generete “tm:local-request” event. Is it possible to activate a parameter in the TM or TMX module to generate the event? Thanks Juan -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3831 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3831(a)github.com>

4 12

[kamailio/kamailio] siptrace: handle trace_to_database param at runtime (PR #3877)
by Gustavo Almeida 27 Sep '24

27 Sep '24

#### Pre-Submission Checklist - [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:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description This change allows to enable/disable the insertion of SIP traces into the DB at runtime (i know we could do this with `siptrace.status`, but this is a different case). This feature is strictly important if you start `Kamailio` with `trace_to_database` parameter disabled, and you want to enable it later and at runtime. Nowadays, if you try to start `Kamailio` with `trace_to_database` enabled, but without a connection to the DB, the service won't start (`child_init` logic). In this type of situation, it makes sense to start `Kamailio` disabling the `trace_to_database` parameter, and when the DB is ok, at runtime, we enable `trace_to_database` parameter. This prevents the need to restart the service, and also we can start `Kamailio` without problems, if DB of SIP Traces is NOK at that time. My PR may need some improvements, especially on the enable side, so feel free to make any changes to improve that. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3877 -- Commit Summary -- * siptrace: handle trace_to_database param at runtime -- File Changes -- M src/modules/siptrace/siptrace.c (100) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3877.patch https://github.com/kamailio/kamailio/pull/3877.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3877 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3877(a)github.com>

4 14

[kamailio/kamailio] core: add support for custom log function (PR #3902)
by Nirv.Ana 26 Sep '24

26 Sep '24

#### Pre-Submission Checklist    - [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:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description Allow Kamailio modules to register their log function so that all Kamailio log messages (coming from core and other modules) are logged uniformly in the format defined by the custom log function. To enable the custom log format feature, Kamailio must be compiled with the `CUSTOM_LOG_FMT` flag. Then the module that wishes to modify the log format has to call `km_custom_log_func_set` during the initialization to supply a custom log formatting function (see `km_default_custom_log_func` as an example). You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3902 -- Commit Summary -- * core: add support for custom log function -- File Changes -- M src/core/dprint.c (19) M src/core/dprint.h (47) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3902.patch https://github.com/kamailio/kamailio/pull/3902.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3902 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3902(a)github.com>

4 19

[kamailio/kamailio] TM crash when relaying reply, in context of unreachable rtpengine (Issue #3297)
by Alex Balashov 22 Sep '24

22 Sep '24

When relaying this `200 OK` repeatedly with calls to `rtpengine_answer()` failing because all RTPEngines in a set are unreachable... ``` Dec 8 06:24:38 gw kamailio[4823]: ERROR: rtpengine [rtpengine.c:2960]: select_rtpp_node(): rtpengine failed to select new for calllen=36 callid=8279a4ea-151e-48de-a23c-5840104126de ``` ``` SIP/2.0 200 OK v:SIP/2.0/UDP 10.150.20.20;branch=z9hG4bK03e.e4da444e627bb575ef4f46151729a1fa.0,SIP/2.0/UDP 10.151.20.108;received=10.151.20.108;rport=5060;branch=z9hG4bKKQyrBKpp04X0K Record-Route:<sip:10.150.20.20;lr;ftag=emHm2apy95jFe;rtp_relay=1;rtp_group=0> f:"14045551212"<sip:14045551212@10.151.20.108>;tag=emHm2apy95jFe t:<sip:16782001111@internal.evaristesys.com>;tag=tHQt0rDcF7UHK i:8279a4ea-151e-48de-a23c-5840104126de CSeq:60686471 INVITE m:<sip:16782001111@10.160.10.55:5060;transport=udp> User-Agent:VoiceAppServer Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,REFER,NOTIFY k:path,replaces u:talk,hold,conference,refer c:application/sdp Content-Disposition:session l:257 v=0 o=DM 1670428117 1670428118 IN IP4 10.160.10.55 s=DM c=IN IP4 10.160.10.55 t=0 0 m=audio 52418 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=rtcp:52419 IN IP4 10.160.10.55 ``` Repeat INVITEs eventually result in a crash. This backtrace is taken from a different server but identical scenario: ``` #0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40, reply=0x7f4afe40df70) at t_reply.c:1285 1285 && !(inv_through && Trans->uac[branch].last_received<300)) { Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.192.el6.x86_64 jansson-2.11-1.el6.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-57.el6.x86_64 libcom_err-1.41.12-22.el6.x86_64 libev-4.03-3.el6.x86_64 libselinux-2.0.94-7.el6.x86_64 libunistring-0.9.3-5.el6.x86_64 openssl-1.0.1e-48.el6_8.3.x86_64 sqlite-3.6.20-1.el6_7.2.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) where #0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40, reply=0x7f4afe40df70) at t_reply.c:1285 #1 0x00007f4afd73ab7d in relay_reply (t=0x7f4aee56ba80, p_msg=0x7f4afe40df70, branch=0, msg_status=200, cancel_data=0x7ffd8b8bbe40, do_put_on_wait=1) at t_reply.c:1821 #2 0x00007f4afd740c38 in reply_received (p_msg=0x7f4afe40df70) at t_reply.c:2558 #3 0x00000000004b5d6a in do_forward_reply (msg=0x7f4afe40df70, mode=0) at core/forward.c:747 #4 0x00000000004b78c9 in forward_reply (msg=0x7f4afe40df70) at core/forward.c:852 #5 0x000000000054982b in receive_msg ( buf=0xb27700 "SIP/2.0 200 OK\r\nv:SIP/2.0/UDP xxx;branch=z9hG4bK9915.dcfe6d03cb21e6c94a6705adb095c566.0,SIP/2.0/UDP xxx;received=xxx;rport=5060;branch=z9hG4bKZmZp0NZv3FvQB\r\nRecord-Rout"..., len=984, rcv_info=0x7ffd8b8bc6c0) at core/receive.c:434 #6 0x00000000006658ca in udp_rcv_loop () at core/udp_server.c:541 #7 0x000000000042500f in main_loop () at main.c:1655 #8 0x000000000042c5bb in main (argc=11, argv=0x7ffd8b8bcc88) at main.c:2696 ``` Looks like in the crash frame, `Trans->uac` is `NULL`: ``` (gdb) frame 0 #0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40, reply=0x7f4afe40df70) at t_reply.c:1285 1285 && !(inv_through && Trans->uac[branch].last_received<300)) { (gdb) print Trans->uac $1 = (struct ua_client *) 0x0 ``` I have seen this crash from time to time, though it is infrequent. It always seems to occur when there are problems reaching RTPEngine in a timely fashion. This is on Kamailio 5.2.4:de9a03, which I know has long fallen off the back of the maintenance train. However, line 1386 of `t_reply.c` in `master:HEAD` shows that the code is no different now: https://github.com/kamailio/kamailio/blob/master/src/modules/tm/t_reply.c#L… Of course, it's possible that something upstream has changed so as to prevent this state. Otherwise, I suppose a null pointer safety check for `Trans->uac` is recommended. I'd be happy to submit a patch, just wasn't sure if the feeling was more that this should be resolved higher up the call stack. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3297 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3297(a)github.com>

2 3

[kamailio/kamailio] core/tcp_main: Match protocol when lookup tcp/tls connections (PR #3810)
by Xenofon Karamanos 21 Sep '24

21 Sep '24

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] 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) - [x] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue [reported in lists](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.k… #### Description  This PR aims to fix a bug/security issue where data that was supposed to be encrypted and transferred through TLS, were transferred instead with TCP protocol. More information and how to replicate can be found in the above [issue](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.k… in list. This PR suggests using also the protocol to match if a TCP connection exists, and when doing connection lookups, otherwise, it might return a wrong connection, ie a TCP one when we are asking for a TLS one (a case when source ip/port and dest IP are same but dest port is set 0 (wildcard) ). `tcpconn_get` was left unchanged due to being used by some modules and not wanting to break them. Please advise whether it should be beneficial to also change it. In some cases like, `tcpconn_add_alias` and `tcpconn_get` we used the `PROTO_NONE` which preserves the original behavior. `tcpconn_add_alias` we do have the protocol available, should it be also used? `tcpconn_get` does not have the protocol available unless we pass it as an argument. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3810 -- Commit Summary -- * tcp_main: Add protocol argument for searching tcp/tls connections * tcp_main: Add proto argument to tcpconn_exists function * tcp_main: Update comment docs * core/forward: Match protocol when forwarding * tcp_main: Match wss protocol -- File Changes -- M src/core/forward.h (3) M src/core/tcp_conn.h (3) M src/core/tcp_main.c (43) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3810.patch https://github.com/kamailio/kamailio/pull/3810.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3810 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3810(a)github.com>

5 10

[kamailio/kamailio] New weighted distribution over hash algorithm for dispatcher module. (Issue #3916)
by Ben Kaufman 08 Sep '24

08 Sep '24

### Description Feature request/suggestion: Currently, the predicative hashing algorithm for dispatcher gives equal weight to all members of the set. It would be convenient to use the rweight attribute to allow something like [weighted rendezvous hashing](https://en.wikipedia.org/wiki/Rendezvous_hashing#Weighted_rendezvo… to provide weighted load balancing will still keeping correct routing for stateless messages (most specifically CANCELs). -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3916 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3916(a)github.com>

2 2

[kamailio/kamailio] Kemi app_python3 throws a TypeError (Issue #3915)
by michelpelletier07 29 Aug '24

29 Aug '24

### Description I am using Kemi with the app_python3 module. I was getting what appeared to be random TypeError exceptions thrown within the Kamailio app_python3 module. I later discovered that this only happened when calling a Kamailio function that exceeded the duration specified in the latency_limit_action core parameter. Also, the line printed in the logs displayed Null values in the 'file:' and 'func:' fields. #### Reproduction To reproduce the issue: 1. You must be using Kemi with the app_python3 module, with the cfgengine set to python. 2. Set the following in your kamailio.cfg file: ``` latency_log=2 latency_limit_action=100000 ``` 3. Run a Kemi function call that takes more time than the latency_limi_action set above. You may have to lower it if your computer is a fast runner. Here is my suggested code: ``` jsreload = dict() jsreload["jsonrpc"] = "2.0" jsreload["method"] = "tls.reload" jsreload["id"] = 1 KSR.jsonrpcs.exec(json.dumps(jsreload)) ``` 4. Use python version 3.11 #### Log Messages 45(324) INFO: app_python3 [apy_kemi.c:377]: sr_apy_kemi_exec_func(): alert - action KSR.jsonrpcs.exec(...) took too long [752946 ms] (file:(null) func:(null) line:491) 45(324) ERROR: app_python3 [python_support.c:167]: python_handle_exception(): apy_exec: ksr_rtimer_dodebug(rtimer): Unhandled exception in the Python code: TypeError: expected bytes, str found The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/etc/kamailio/kamailio.py", line 491, in ksr_rtimer_dodebug KSR.jsonrpcs.exec(json.dumps(jsreload)) SystemError: <built-in function exec> returned a result with an exception set ### Possible Solutions The solution is to replace PyBytes_AsString(..) calls with calls to PyUnicode_AsUTF8(..) in the PY_VERSION_HEX >= 0x030B0000 block of apy_kemi.c. The PyBytes_AsString expects a Bytes value but reeives a Unicode value instead, thus causing the TypeError exception. Enclosed is a patch file with the fix implemented: [kamailio-5.8.2.patch.txt](https://github.com/user-attachments/files/1619573… ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` # kamailio -v version: kamailio 5.8.2 (x86_64/linux) 3fa5f4 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, 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_SEND_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: 3fa5f4 compiled on 09:58:55 Jul 12 2024 with gcc 12.2.0 ``` * **Operating System**:  ``` # uname -a Linux xxxxxxxxxxxxxxxxxxx 5.10.0-30-amd64 #1 SMP Debian 5.10.218-1 (2024-06-01) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3915 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3915(a)github.com>

4 8

[kamailio/kamailio] sca: add support custom [to|from]_uri (PR #3930)
by Victor Seva 27 Aug '24

27 Aug '24

#### Pre-Submission Checklist    - [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:  - [ ] PR should be backported to stable branches - [x] Tested changes locally #### Description This is the first step to merge the functionality that is already used in Sipwise kamailio flavor * module parameters [from|to]_uri_avp to store * sca_handle_subscribe() support [from|to_uri] parameters Add the possibility of define what is the URI value for To and/or From instead of the values from the SIP message You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3930 -- Commit Summary -- * sca: add support custom [to|from]_uri -- File Changes -- M src/modules/sca/doc/sca.xml (58) M src/modules/sca/doc/sca_admin.xml (52) M src/modules/sca/sca.c (115) M src/modules/sca/sca.h (5) M src/modules/sca/sca_call_info.c (190) M src/modules/sca/sca_subscribe.c (96) M src/modules/sca/sca_subscribe.h (5) M src/modules/sca/sca_util.c (184) M src/modules/sca/sca_util.h (19) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3930.patch https://github.com/kamailio/kamailio/pull/3930.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3930 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3930(a)github.com>

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2024