Module: kamailio
Branch: master
Commit: ad35c24196c921a3e870f4a48b6d286748d78d48
URL: https://github.com/kamailio/kamailio/commit/ad35c24196c921a3e870f4a48b6d286…
Author: Xenofon Karamanos <xk(a)gilawa.com>
Committer: Xenofon Karamanos <xk(a)gilawa.com>
Date: 2024-12-30T15:48:15Z
cmake: Update min version required to 3.10
---
Modified: cmake/compiler-specific.cmake
Modified: cmake/defs.cmake
Modified: cmake/os-specific.cmake
Modified: src/modules/CMakeLists.txt
Modified: src/modules/presence/CMakeLists.txt
Modified: src/modules/presence_xml/CMakeLists.txt
Modified: utils/kamctl/CMakeLists.txt
---
Diff: https://github.com/kamailio/kamailio/commit/ad35c24196c921a3e870f4a48b6d286…
Patch: https://github.com/kamailio/kamailio/commit/ad35c24196c921a3e870f4a48b6d286…
---
diff --git a/cmake/compiler-specific.cmake b/cmake/compiler-specific.cmake
index 7ecd87b75ad..950b64941ab 100644
--- a/cmake/compiler-specific.cmake
+++ b/cmake/compiler-specific.cmake
@@ -2,7 +2,6 @@
# common flags and options for the project The flags are defined as INTERFACE
# properties of the common library The flags are then used by the other
# libraries and executables
-cmake_minimum_required(VERSION 3.10)
# Define the common flags and options for GCC
option(PROFILE "Enable profiling" OFF)
diff --git a/cmake/defs.cmake b/cmake/defs.cmake
index bc08b2ce4ac..a01a43eaf65 100644
--- a/cmake/defs.cmake
+++ b/cmake/defs.cmake
@@ -2,7 +2,6 @@
# common flags and options for the project The flags are defined as INTERFACE
# properties of the common library The flags are then used by the other
# libraries and executables
-cmake_minimum_required(VERSION 3.10)
add_library(common INTERFACE)
diff --git a/cmake/os-specific.cmake b/cmake/os-specific.cmake
index 7fbbd4763a2..d70a44cf379 100644
--- a/cmake/os-specific.cmake
+++ b/cmake/os-specific.cmake
@@ -1,8 +1,7 @@
-# Quite analogous to the Makefile.defs file
-# This file is used to define the common flags and options for the project
-# The flags are defined as INTERFACE properties of the common library
-# The flags are then used by the other libraries and executables
-cmake_minimum_required(VERSION 3.10)
+# Quite analogous to the Makefile.defs file This file is used to define the
+# common flags and options for the project The flags are defined as INTERFACE
+# properties of the common library The flags are then used by the other
+# libraries and executables
set(OS_SPECIFIC_DIR "${CMAKE_SOURCE_DIR}/cmake/os-specific")
if(CMAKE_SYSTEM_NAME STREQUAL "Linux")
diff --git a/src/modules/CMakeLists.txt b/src/modules/CMakeLists.txt
index a1b474a4502..6570b4afdf2 100644
--- a/src/modules/CMakeLists.txt
+++ b/src/modules/CMakeLists.txt
@@ -73,6 +73,7 @@ function(add_module_group group_modules)
if(POLICY CMP0079)
cmake_policy(SET CMP0079 NEW)
endif()
+
target_link_libraries(${module_name} PRIVATE common_modules)
target_compile_definitions(
${module_name} PRIVATE MOD_NAMEID=${module_name}
diff --git a/src/modules/presence/CMakeLists.txt b/src/modules/presence/CMakeLists.txt
index dbac5d4862e..ef19545fcb2 100644
--- a/src/modules/presence/CMakeLists.txt
+++ b/src/modules/presence/CMakeLists.txt
@@ -1,6 +1,3 @@
-# 3.12 For libxml2 target
-cmake_minimum_required(VERSION 3.12)
-
file(GLOB MODULE_SOURCES "*.c")
add_library(${module_name} SHARED ${MODULE_SOURCES})
diff --git a/src/modules/presence_xml/CMakeLists.txt b/src/modules/presence_xml/CMakeLists.txt
index dbac5d4862e..ef19545fcb2 100644
--- a/src/modules/presence_xml/CMakeLists.txt
+++ b/src/modules/presence_xml/CMakeLists.txt
@@ -1,6 +1,3 @@
-# 3.12 For libxml2 target
-cmake_minimum_required(VERSION 3.12)
-
file(GLOB MODULE_SOURCES "*.c")
add_library(${module_name} SHARED ${MODULE_SOURCES})
diff --git a/utils/kamctl/CMakeLists.txt b/utils/kamctl/CMakeLists.txt
index 2b017836025..75208d63222 100644
--- a/utils/kamctl/CMakeLists.txt
+++ b/utils/kamctl/CMakeLists.txt
@@ -1,5 +1,3 @@
-cmake_minimum_required(VERSION 3.10)
-
project(kamailio_utils)
# if(NOT basedir) set(KAMCTL_TMP_DIR "/tmp") else() set(KAMCTL_TMP_DIR
<!-- 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 -->
- [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:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
##### **Summary**
This update introduces new functionality to the `secfilter` module, enabling the removal of entries from both the Blacklist and Whitelist. It also includes automatic detection and removal of duplicate values from these lists.
##### **Details**
* Users can now remove specific entries from the Blacklist or Whitelist based on type (e.g., IP, domain, user) and a given value.
* Supports removal of single or multiple matching entries in one operation.
##### **Benefits**
- Improves the usability and flexibility of the `secfilter` module by allowing fine-grained control over list management.
- Ensures that the Blacklist and Whitelist are kept clean and free from redundant entries.
- Enhances performance by reducing unnecessary duplication in the lists.
##### Testing
This feature was tested using `kmcmd` commands in various scenarios:
- Removing the **first element** in the list.
- Removing an element from the **middle** of the list.
- Removing the **last element** in the list.
- Removing **all matching elements** in the list.
In all cases, the commands worked correctly, and the lists were updated and cleaned as expected.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4086
-- Commit Summary --
* secfilter: support remove rule in Whitelist and Blacklist
* Merge remote-tracking branch 'origin/master' into Feature/5-support-remove-rule-in-Whitelist-Blacklist
* secfilter: support remove rule in Whitelist and Blacklist
* edit end of file
-- File Changes --
M src/modules/secfilter/secfilter.c (8)
M src/modules/secfilter/secfilter.h (3)
M src/modules/secfilter/secfilter_db.c (106)
M src/modules/secfilter/secfilter_rpc.c (94)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4086.patchhttps://github.com/kamailio/kamailio/pull/4086.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4086
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4086(a)github.com>
### Description
In Prometheus there is the possibility to tag values with tags. Those tags can then be used provide context to those values, for example to filter them.
### Expected behavior
It would be great if there was a way to provide custom tags to the metrics. These would essentially just be a static string between the name of the metric and its value.
Example:
`system_load15{host="wurst23.dev.sipgate.net",hostname_short="wurst32"} 0.4`
This could probably be achieved by having an `xhttp_prom_ending` parameter similar to the `xhttp_prom_beginning` as we essentially just want to append a static string right after the metric name.
#### Actual observed behavior
`kamailio_sip_lb_de_core_rcv_replies_1xx_invite 1773 1731419851663`
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4021
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4021(a)github.com>
Hi There,
We found a situation where topos seems to break, let me explain... Assuming the following scenario:
```
Caller ---- Callee
A: ------INVITE-----> Record-Route:A.A.A.A, Record-Route:B.B.B.B
B: <-----200 OK------
C: <-----INVITE------ Route: A.A.A.A, B.B.B.B
D: ------200 OK-----> Record-Route:B.B.B.B, Record-Route:A.A.A.A (reversed order)
E: <======INVITE===== Route: B.B.B.B, A.A.A.A (wrong)
```
A and B establish the connection from caller to callee, and topos works fine.
C (re-INVITE from callee) sends the Route header according to the Record-Routes from the original INVITE (A)
D is the 200 OK sent from the caller to the first re-INVITE (C) coming from the callee, with the Record-Route headers reversed, because is the order in which the callee received them; and according to the RFC it's working as intended:
```
When a UAS responds to a request with a response that establishes a
dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
header field values from the request into the response (including the
URIs, URI parameters, and any Record-Route header field parameters,
whether they are known or unknown to the UAS) and MUST maintain the
order of those values.
[...]
[When a UAC receives a response...]
The route set MUST be set to the list of URIs in the Record-Route
header field from the response, taken in reverse order and preserving
all URI parameters.
```
E takes the Route order from the last 200 OK ignoring they are in reversed order and assuming the top one is the first one, when it should be the other way around, sending to an IP address not reachable from the callee. And I think here is the issue, topos should not update the path on the Record-Routes from a 200 OK but if it does, it should take the reverse order
When disabling topos, everything works fine, or with topos enabled, by setting rr_update=0 works for us, but what if there is a real path update, rr_update=0 wouldn't work for us anymore. The Kamailio version is 5.8.0-rc0
Let me know if you need more information.
Thanks a lot,
Javi
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3778
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3778(a)github.com>
I noticed at least two styles of CMakeLists.txt for modules:
```
❯ cat src/modules/acc/CMakeLists.txt
file(GLOB acc_SRC "*.c")
add_library(acc SHARED ${acc_SRC})
```
and
```
❯ cat src/modules/xlog/CMakeLists.txt
file(GLOB SRC_FILES "*.c")
add_library(xlog SHARED ${SRC_FILES})
# # target_link_libraries(.*PRIVATE)
```
Which one should be used? The one with `modname_SRC` (e.g., `acc_SRC`) or the one with `SRC_FILES`?
Also, I guess that the comment with `target_link_libraries()` can be removed.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4081
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4081(a)github.com>