sr-dev February 2024

sr-dev@lists.kamailio.org

19 participants
242 discussions

[kamailio/kamailio] xhttp: fix execution of async functions (PR #3723)

by Vadim Saranov

#### 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 - [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 - [x] Related to issue #3720 #### Description Fixing R-RURI and adding necessary headers when creating fake_msg in xhttp_mod.c for successful message validation and the ability to perform various kamailio functions from event_route[xhttp:request]. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3723 -- Commit Summary -- * xhttp: fix execution of async functions -- File Changes -- M src/modules/xhttp/xhttp_mod.c (39) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3723.patch https://github.com/kamailio/kamailio/pull/3723.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3723 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3723(a)github.com>

8 months, 1 week

[kamailio/kamailio] Docs: TLS module known limitation needs clarifications (Issue #3717)

by Thierno IB. BARRY

### Description We recently deployed successfully Kamailio with TLS certificates. Now we would like to use let's encrypt certificate which expire after 3 months. Means we need to renew certificate approximatively every 2 months. But while reading docs, in [known limitations](https://kamailio.org/docs/modules/devel/modules/tls.html#tls.k… it says : > TLS specific config reloading is not safe, so for now better don't use it, especially under heavy traffic. We struggle to understand if this behaviour is risky and not recommended under heavy traffic for certificate renewal. The doc has been added initially by @poandrei 18 years ago in Feb 21 2007 (see [commit](https://github.com/kamailio/kamailio/commit/32e4977cdb9c1c9ca24c140…) While digging we came across few discussions Kamailio user groups which are saying "the opposite" (kind of): - [Comments by a co-founder of Kamailio ](https://www.mail-archive.com/sr-users@lists.kamailio.org/msg16014.html)stating that the old connections shouldn’t be affected by reload. - Comments by a Kamailio core developer stating that certificate reload is fine with the “reload” cmd ([link1](https://lists.kamailio.org/pipermail/sr-users/2022-February/114296.h…, [link2](https://github.com/kamailio/kamailio/issues/3305)) Plus in another section in docs: - [By definition :](https://kamailio.org/docs/modules/devel/modules/tls.html#tls.r.tls.reload) (the) existing active TLS connections are not terminated and they continue to use the old certificates. The new configuration will be used for new connections. So 18 years after, Is it safe to use `tls.reload` command in production and in heavy traffic for **TLS certificate renewal** ? Because it sounds scary and confusing. So the documentation as it is, really needs clarifications to let users know which risk they're taking when running the `tls.reload` command.  ### Expected behavior The document should clearly documents risks, at least for certificate renewal. #### Actual observed behavior Docs and Kamailio user/dev groups are confusing. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3717 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3717(a)github.com>

8 months, 2 weeks

[kamailio/kamailio] Dispatcher: added two new flags to mode parameter of ds_is_from_list function for more strictly matching (PR #3699)

by Dennis

#### 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 - [ ] 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 - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description This PR adds 2 new flags to the mode parameter of the ds_is_from_list function. Some times the dispatcher configuration can look like this (route attribute is just for exampe, sockname is important here): 70 sip:192.168.1.1:5060;transport=udp 0 1 route=route1;sockname=udp_5060 71 sip:192.168.1.1:5060;transport=udp 0 1 route=route2;sockname=udp_5061 72 sip:192.168.1.1:5060;transport=udp 0 1 route=route3;sockname=udp_5062 73 sip:192.168.1.1:5060;transport=udp 0 1 route=route4;sockname=udp_5063 Here we have one host/port/protocol on the remote side and different ports that we are listening on, In stock dispatcher version ds_is_from_list(-1,0) will always match first available - 70, but this is not right for dst ports 5061-5063 (sockets in realality, because we can have different local ip on same port also). The new mode flag DS_MATCH_SOCKET (8) allow match for dispatcher socket also. Second flag is DS_MATCH_STRICTEST (16), it allow to match more strictness target in "address/protocol/port/socket" key, for example: 70 sip:192.168.1.1;transport=udp 0 1 route=route1 71 sip:192.168.1.1:5061;transport=udp 0 1 route=route2 72 sip:192.168.1.1:5062;transport=udp 0 1 route=route3 73 sip:192.168.1.1;transport=udp 0 1 route=route4;socket=udp:192.168.10.10:5063 if packet come from from any port of sip:192.168.1.1;transport=udp except 5061-5062 ds_is_from list will return 70, if received port also is 5063 the result will be 73, packets from ports 5061-5062 will be matched at 71-72 respectively. In stock version of ds_is_from_list the result will always be 70. Note, the DS_MATCH_STRICTEST method can be more compute intensive, because we can potentially traverse all the dispatcher tree. The behavior of existing flags are not changed. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3699 -- Commit Summary -- * dispatcher: added two new flags to mode parameter of ds_is_from_list function for more strictly matching -- File Changes -- M src/modules/dispatcher/dispatch.c (112) M src/modules/dispatcher/dispatch.h (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3699.patch https://github.com/kamailio/kamailio/pull/3699.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3699 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3699(a)github.com>

8 months, 2 weeks

Roadmap to next major Kamailio release series v5.8.x

by Daniel-Constantin Mierla

Hello, discussed a bit during the online Kamailio devel meeting, it is time to set the milestones towards the next major Kamailio release series v5.8.x. If no other suggestions that suit more developers, I would propose to freeze by end of this month or early February, then test for about 4 weeks as usual and release by end of February or during March. If anyone wants to add new features/modules, they have to be published till freezing date, either pushed in the git repository or proposed as pull request. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, February 20-22, 2024 -- asipto.com Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com

8 months, 3 weeks

[kamailio/kamailio] secfilter.reload does not work for destination block list (Issue #3694)

by Ali

Hi When I add a destination to MySQL server to block and use kamcmd to reload, the call will not be blocked, while if I use kamcmd to add destination with `secfilter.add_dst` it works properly. It's considerable that after reloading if I print the blocked list in kamcmd (with `secfilter.print`) new database row will be printed correctly. my secfilter SQL table: +----+--------+------+------+ | id | action | type | data | +----+--------+------+------+ | 1 | 2 | 4 | 1111 | +----+--------+------+------+ kamailio 5.4.6 (x86_64/linux) Ubuntu 22.04.3 LTS -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3694 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3694(a)github.com>

8 months, 3 weeks

[kamailio/kamailio] uac_reg_unregister(attr, val) (Issue #3702)

by QWERTY

The uac module lacks the uac_reg_unregister(attr, val) method, Send REGISTER with expires 0 for matching record in real time, instead of through RPC command。uac_reg_disable(attr, val) ：SIP processing is done on the next timer routine. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3702 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3702(a)github.com>

8 months, 3 weeks

git:5.7:e66915b9: tls: fix OpenSSL 1.1.1 engine keys

by S-P Chan

Module: kamailio Branch: 5.7 Commit: e66915b95fda66ab9d2981854894707813e331ee URL: https://github.com/kamailio/kamailio/commit/e66915b95fda66ab9d2981854894707… Author: S-P Chan <shihping.chan(a)gmail.com> Committer: S-P Chan <shihping.chan(a)gmail.com> Date: 2024-02-29T19:05:57+08:00 tls: fix OpenSSL 1.1.1 engine keys Cherry-pick from e535cc5eb2 --- Modified: src/modules/tls/tls_mod.c --- Diff: https://github.com/kamailio/kamailio/commit/e66915b95fda66ab9d2981854894707… Patch: https://github.com/kamailio/kamailio/commit/e66915b95fda66ab9d2981854894707… --- diff --git a/src/modules/tls/tls_mod.c b/src/modules/tls/tls_mod.c index 664e35f7c33..85a1fc4cd9e 100644 --- a/src/modules/tls/tls_mod.c +++ b/src/modules/tls/tls_mod.c @@ -728,6 +728,7 @@ static int tls_engine_init() * We are in the child process and the global engine linked-list * is initialized in the parent. */ + ENGINE_load_builtin_engines(); e = ENGINE_by_id("dynamic"); if(!e) { err = "Error loading dynamic engine";

8 months, 4 weeks

git:master:e535cc5e: tls: fix OpenSSL 1.1.1 engine keys

by S-P Chan

Module: kamailio Branch: master Commit: e535cc5eb2d81a67d00931bb53328953ec8ef492 URL: https://github.com/kamailio/kamailio/commit/e535cc5eb2d81a67d00931bb5332895… Author: S-P Chan <shihping.chan(a)gmail.com> Committer: S-P Chan <shihping.chan(a)gmail.com> Date: 2024-02-29T19:01:14+08:00 tls: fix OpenSSL 1.1.1 engine keys --- Modified: src/modules/tls/tls_mod.c --- Diff: https://github.com/kamailio/kamailio/commit/e535cc5eb2d81a67d00931bb5332895… Patch: https://github.com/kamailio/kamailio/commit/e535cc5eb2d81a67d00931bb5332895… --- diff --git a/src/modules/tls/tls_mod.c b/src/modules/tls/tls_mod.c index 550a1bcc2b5..322be20bd8e 100644 --- a/src/modules/tls/tls_mod.c +++ b/src/modules/tls/tls_mod.c @@ -728,6 +728,7 @@ static int tls_engine_init() * We are in the child process and the global engine linked-list * is initialized in the parent. */ + ENGINE_load_builtin_engines(); e = ENGINE_by_id("dynamic"); if(!e) { err = "Error loading dynamic engine";

8 months, 4 weeks

git:5.8:f53c6b49: tls: fix OpenSSL 1.1.1 engine keys

by S-P Chan

Module: kamailio Branch: 5.8 Commit: f53c6b49e158203ba0783ec6a6fbadd76c5fdde9 URL: https://github.com/kamailio/kamailio/commit/f53c6b49e158203ba0783ec6a6fbadd… Author: S-P Chan <shihping.chan(a)gmail.com> Committer: S-P Chan <shihping.chan(a)gmail.com> Date: 2024-02-29T19:02:03+08:00 tls: fix OpenSSL 1.1.1 engine keys Cherry-pick from e535cc5eb2 --- Modified: src/modules/tls/tls_mod.c --- Diff: https://github.com/kamailio/kamailio/commit/f53c6b49e158203ba0783ec6a6fbadd… Patch: https://github.com/kamailio/kamailio/commit/f53c6b49e158203ba0783ec6a6fbadd… --- diff --git a/src/modules/tls/tls_mod.c b/src/modules/tls/tls_mod.c index 550a1bcc2b5..322be20bd8e 100644 --- a/src/modules/tls/tls_mod.c +++ b/src/modules/tls/tls_mod.c @@ -728,6 +728,7 @@ static int tls_engine_init() * We are in the child process and the global engine linked-list * is initialized in the parent. */ + ENGINE_load_builtin_engines(); e = ENGINE_by_id("dynamic"); if(!e) { err = "Error loading dynamic engine";

8 months, 4 weeks

[kamailio/kamailio] Fixes related to contact updation and searching in P-CSCF modules (PR #3771)

by Supreeth Herle

9 months

← Newer
1
2
3
4
5
6
7
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev February 2024