nicthenothing created an issue (kamailio/kamailio#4436)
Description
When using Kamailio IMS (from docker_open5gs setup) as the P-CSCF, SIP calls fail to initiate when the UE’s signaling (“ear” channel) and media (“mouth” channel) are bound to different ports or sockets.
In the captured logs, the Request-URI and the Destination-URI differ in both port and alias parameters, resulting in the INVITE not being routed properly through the IPSec tunnel.
It seems that Kamailio does not correctly resolve the IPSec tunnel when the UE’s contact and destination information differ (possibly due to alias handling or flag configuration).
This issue may relate to improper handling of the alias parameter or flag mismatch between use_dst_uri and use_contact.
---
Troubleshooting
Reproduction
1. Deploy the default IMS setup from herlesupreeth/docker_open5gs (Kamailio + Open5GS).
2. Attach a UE over IPSec where its signaling and media sockets differ (e.g., TCP vs UDP port mismatch).
3. Initiate a SIP INVITE from UE-A to UE-B.
4. Observe that INVITE fails to reach the destination.
Debugging Data
N/A (default Docker config used)
Log Messages
2025-10-15T13:21:33.638305291Z Destination URI: sip:10.20.7.216:42602;transport=tcp
2025-10-15T13:21:33.638307845Z Request URI: sip:3c7a3414-8cf7-458e-a674-9181ea0ccd15@10.20.7.216:42078
---
SIP Traffic
Request-Line: INVITE sip:578da559-1f6e-430f-a953-8e4dfc99918e@10.20.7.228:40404;alias=10.20.7.228~43426~2 SIP/2.0
Request-URI: sip:578da559-1f6e-430f-a953-8e4dfc99918e@10.20.7.228:40404;alias=10.20.7.228~43426~2
Request-URI User Part: 578da559-1f6e-430f-a953-8e4dfc99918e
Request-URI Host Part: 10.20.7.228
Request-URI Host Port: 40404
---
Possible Solutions
Validate handling of alias parameter in IPSec tunnel search logic.
Verify if flag 4 (Use destination URI for IPSec tunnel search) or flag 8 (Use new R-URI for IPSec tunnel search) needs adjustment in modparam("ipsec", "flag", X) for correct behavior.
Potential fix may involve extending alias resolution to new R-URI before tunnel lookup.
---
Additional Information
Kamailio Version:
version: kamailio 5.7.x (from docker_open5gs)
Operating System:
Ubuntu 22.04 (containerized)
Linux 5.15.0-122-generic
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4436
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4436(a)github.com>
Den4t created an issue (kamailio/kamailio#4391)
Hi !
Kamailio v.5.8.6, used as webrtc registrar/GW, wolfssl v.5.7.4, high call load, OS: Ubuntu 22
Periodically kamailio dumps core with assertion:
```
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140585212159808) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) backtrace
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140585212159808) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=140585212159808) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=140585212159808, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007fdc8ba5f476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007fdc8ba457f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007fdc8ba4571b in __assert_fail_base (fmt=0x7fdc8bbfa130 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fdc7a6b299f "nw == bytes_read", file=0x7fdc7a6b089a "tls_server.c", line=1056, function=<optimized out>) at ./assert/assert.c:94
#6 0x00007fdc8ba56e96 in __GI___assert_fail (assertion=0x7fdc7a6b299f "nw == bytes_read", file=0x7fdc7a6b089a "tls_server.c", line=1056, function=0x7fdc7a6b5068 "tls_h_read_f") at ./assert/assert.c:103
#7 0x00007fdc7a48cd89 in tls_h_read_f () from /usr/lib64/kamailio/modules/tls_wolfssl.so
#8 0x00005622baa30e8e in ?? ()
#9 0x00005622baa3273b in tcp_read_req ()
#10 0x00005622baa3c7c2 in ?? ()
#11 0x00005622babf61d6 in ?? ()
#12 0x00005622baa42b87 in tcp_receive_loop ()
#13 0x00005622baa24188 in tcp_init_children ()
#14 0x00005622ba7b1b33 in main_loop ()
#15 0x00005622ba7a5888 in main ()
```
I couldn't reproduce this issue in a lab, but I think that possibly the issue depends on TLS traffic burst behavior.
We have some buggy webrtc clients, which floods using MESSAGE requests with high CPS periodically.
I assume that might be this traffic somehow fills the BIO buffers in wolfssl. As result wolfSSL_BIO_write function returns with error.
I have no time to debug deeply, so I made a quick fix here:
https://github.com/Den4t/kamailio/commit/20579f02354356dedb5f5ac1f9bff65314…
I see following logs after the fix has been applied:
```
2025-09-02T09:24:04.393019+03:00 iptel /usr/sbin/kamailio[892554]: BUG: tls_wolfssl [tls_server.c:1058]: tls_h_read_f(): tls_h_read_f assertion check nw == bytes_read (nw=-1, bytes_read=7115,
npos=-1)
2025-09-02T10:44:21.556481+03:00 iptel /usr/sbin/kamailio[892559]: BUG: tls_wolfssl [tls_server.c:1058]: tls_h_read_f(): tls_h_read_f assertion check nw == bytes_read (nw=-1, bytes_read=6201,
npos=-1)
2025-09-02T10:58:31.563456+03:00 iptel /usr/sbin/kamailio[892558]: BUG: tls_wolfssl [tls_server.c:1058]: tls_h_read_f(): tls_h_read_f assertion check nw == bytes_read (nw=-1, bytes_read=7587,
npos=-1)
```
But service is alive.
It is better to lose one session than the whole service.
In any case this is just a crutch for quick problem fix, so it would be nice if tls_wolfssl module's author took a deeper look at the problem.
P.S.
I assume that module's logic should check BIO flags after the call to wolfSSL_BIO_write, f.e. this function can return error with bio flag WOLFSSL_BIO_FLAG_RETRY set.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4391
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4391(a)github.com>
floo94 created an issue (kamailio/kamailio#4507)
### Description
When an invite contains URL-encoded angle brackets (see example request URI), Topoh crashes with a segfault.
Unfortunately, I don't have the means to produce logs or a core dump at the moment...
Sorry for the poor information. If necessary, I can provide more data later.
### Troubleshooting
#### Reproduction
#### SIP Traffic
Request URI of the INVITE:
```
INVITE sip:%3csip%3aq*testqueue@dev1.test.com>;user=phone|*8 SIP/2.0
```
### Possible Solutions
disabling topoh
### Additional Information
```
version: kamailio 6.0.2 (x86_64/linux) 567a0e
```
* **Operating System**:
```
Distributor ID: Ubuntu
Description: Ubuntu 22.04.5 LTS
Release: 22.04
Codename: jammy
5.15.0-153-generic #163-Ubuntu SMP Thu Aug 7 16:37:18 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4507
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4507(a)github.com>
fulhade created an issue (kamailio/kamailio#4431)
Testing 6.0.3 noticed that log is filled with INFO log messages from title (every 5s). No errors in logs, usual stuff except info on tcpcon
```
Oct 12 00:40:24 kamailio[4350]: INFO: <core> [core/tcp_main.c:3124]: tcpconn_1st_send(): quick connect for 0x7f78f8c79b10 sock 38
Oct 12 22:42:26 kamailio[4355]: INFO: <core> [core/tcp_main.c:3124]: tcpconn_1st_send(): quick connect for 0x7f78f8c79b10 sock 32
...
Oct 13 07:42:12 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
Oct 13 07:42:17 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
Oct 13 07:42:22 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
Oct 13 07:42:27 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
Oct 13 07:42:32 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
Oct 13 07:42:37 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
```
Using docker image built on trixie: https://pastebin.com/0wZ0X9wb
Not sure how to reproduce, it just appear on testing machine after couple of days.
Unfortunately we used 5.6.3 before this, so not sure when did it break for us. http_async_client usage:
```
$http_req(hdr) = "Content-Type: application/json";
$http_req(hdr) = "Expect: ";
$http_req(body) = $dlg_var(http_body);
http_async_query("${URL}/RoutingService/route", "ROUTING_RESPONSE");
```
Memory looks fine, but one of four CPU core spike to 96%.
<img width="1119" height="955" alt="Image" src="https://github.com/user-attachments/assets/ffff8680-84ad-4866-9892-a6e6eefd…" />
core.tcp_info, mod.stats all shm, mod.stats all pkg https://pastebin.com/QLZ8mZdD
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4431
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4431(a)github.com>
miconda created an issue (kamailio/kamailio#4576)
I am trying to figure out what is the best way to specify additional include and library paths for a module.
The particular case right now is `websocket` on `macos` (`darwin`), where `libunistring` is installed via `macports`, but it does not ship a `pkg-config` file, so the option I was looking briefing at would be to add the macports install paths to compiler/linking options `-I` and `-L`:
```
/opt/local/include
/opt/local/lib
```
Considering that most of the libraries come with pkg-config, probably the right place is to add to module's `CMakeLists.txt`. I tried to add some condition on `if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")`, but somehow it doesn't see to work (yet).
On the other hand, I noticed kind of find-specific-library files inside `cmake/modules/`. Should this be the preferred approach?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4576
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4576(a)github.com>
whosgonna created an issue (kamailio/kamailio#4510)
### Description
I came across the following behavior when working with data returned from `rtpengine_query_v()`. Some of the returned data has the `to_tag` and `from_tag` as the key name, and in some cases there is a `.` in the tag, which makes this section of the data unavailable using the `json.parse` transfomration.
Sample data, pretty printed, and most fields removed to make the problem more visible. Note that the key names are the SIP To: tag and From: tag, so they're not something that can be controlled in Kamailio.
```
{
"tags": {
"iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3": {
"label": "customer"
},
"rtmeQtNp5vyBF": {
"label": "vendor"
}
}
}
```
The second tag there would be accessible via the `json.parse` transformation like this:
```
$vn(json) = '{"tags":{"iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3":{"label":"customer"},"rtmeQtNp5vyBF":{"label":"vendor"}}}';
$vn(ft) = "rtmeQtNp5vyBF";
$vn(ft_path) = "tags." + $vn(ft) + ".label";
$vn(ft_label) = $(vn(json){json.parse, $vn(ft_path) });
xnotice("FT Label ($vn(ft_path)): $vn(ft_label)\n");
## output:
## NOTICE: <script>: FT Label (tags.rtmeQtNp5vyBF.label): vendor
```
However, trying to do the same thing with the first tag that contains a dot then has a problem:
```
$vn(json) = '{"tags":{"iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3":{"label":"customer"},"rtmeQtNp5vyBF":{"label":"vendor"}}}';
$vn(tt) = "iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3";
$vn(tt_path) = "tags." + $vn(tt) + ".label";
$vn(tt_label) = $(vn(json){json.parse, $vn(tt_path) });
xnotice("FT Label ($vn(tt_path)): $vn(tt_label)\n");
## output (contains no value):
## NOTICE: <script>: FT Label (tags.iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3.label):
```
The reason for the failure is rather clear: The `.` is being interpolated as the path separator. I believe that it should be possible to quote this portion of the JSONPath, either as `tags."iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3".label` or `tags["iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3"].label`, but I'm not able to find a variation that works.
I will concede that the documentation for the transformation does not explicitly state JSONPath, so perhaps this is a feature add, and not a bug, however JSONPath seems to otherwise be usable here.
### Troubleshooting
#### Reproduction
Reproducible by example above
### Possible Solutions
Allow JSONPath quoting of the string?
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
# kamailio -v
version: kamailio 6.0.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, 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: unknown
compiled on 19:19:24 Nov 24 2025 with cc 14.2.0
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
# cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.22.2
PRETTY_NAME="Alpine Linux v3.22"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
# uname -a
Linux 456b7c5e5e64 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4510
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4510(a)github.com>
<!-- 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
- [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:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [X] PR should be backported to stable branches
- [X] Tested changes locally
- [X] Related to issue #4574
#### Description
<!-- Describe your changes in detail -->
This pull request updates the Prometheus metric label printing logic in `prom_metric.c` to ensure that global tags are always included in the metric output, even when no metric-specific labels are present. The changes also improve how global tags are appended when both user-defined labels and global tags exist.
Label and tag printing improvements:
* Updated `prom_label_print` to print global tags when metric-specific labels are absent, ensuring consistent inclusion of global tags in all metrics.
* Modified both `prom_label_print` and `prom_label_print_le` to append global tags before closing the label braces, so that global tags are always present and correctly formatted. [[1]](diffhunk://#diff-3234c6053b9b93dc271b84392d97cc1c0900a4b4a5b1d62edf71bd48918449c3L1776-R1776) [[2]](diffhunk://#diff-3234c6053b9b93dc271b84392d97cc1c0900a4b4a5b1d62edf71bd48918449c3L1835-R1835)
* Refactored `prom_metric_lvalue_print` to handle the presence of user-defined labels and global tags more robustly: when both are present, labels and tags are combined properly; when only tags are present, only tags are printed in braces.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4575
-- Commit Summary --
* xhttp_prom: include global tags in user-defined metrics
-- File Changes --
M src/modules/xhttp_prom/prom_metric.c (55)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4575.patchhttps://github.com/kamailio/kamailio/pull/4575.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4575
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4575(a)github.com>
#### 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
##### Problem
The default timestamp format (integer milliseconds) in xhttp_prom metrics violates the OpenMetrics specification, which requires timestamps in seconds. Monitoring systems like Grafana Alloy and Mimir reject millisecond timestamps, causing metrics ingestion failures.
##### Solution
Added new module parameter `timestamp_format` with three configuration options:
- **"ms"** (default): Integer milliseconds - maintains backward compatibility
- **"s"**: Integer seconds - OpenMetrics compliant
- **"sf"**: Seconds with fractional milliseconds - OpenMetrics compliant with sub-second precision
##### Testing
- Default behavior tested (parameter omitted defaults to "ms")
- All three timestamp formats validated with regex pattern matching
- Backward compatibility confirmed
- Module compiles cleanly with no warnings
##### Related Files
- Module documentation updated in `doc/xhttp_prom_admin.xml`
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4557
-- Commit Summary --
* xhttp_prom: add timestamp_format parameter
-- File Changes --
M src/modules/xhttp_prom/doc/xhttp_prom_admin.xml (70)
M src/modules/xhttp_prom/prom.c (118)
M src/modules/xhttp_prom/prom.h (9)
M src/modules/xhttp_prom/prom_metric.c (42)
M src/modules/xhttp_prom/xhttp_prom.c (61)
M src/modules/xhttp_prom/xhttp_prom.h (5)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4557.patchhttps://github.com/kamailio/kamailio/pull/4557.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4557
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4557(a)github.com>