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>
#### 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
Adds a SIPp integration module to run automated load tests via Kamailio RPC.
Includes test start/stop/monitoring, domain whitelist and concurrency limits,
remote control commands for pause/resume/rate adjustment, and Prometheus export
via xhttp_prom when enabled.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4581
-- Commit Summary --
* sipp: integrate SIPp for automated load testing via Kamailio RPC
-- File Changes --
M .devcontainer/Dockerfile (2)
A src/modules/sipp/Makefile (9)
A src/modules/sipp/doc/Makefile (4)
A src/modules/sipp/doc/sipp.xml (31)
A src/modules/sipp/doc/sipp_admin.xml (765)
A src/modules/sipp/examples/kamailio.cfg (1198)
A src/modules/sipp/examples/sipp-scenarios/uac_invite.xml (96)
A src/modules/sipp/examples/sipp-scenarios/uac_register.xml (86)
A src/modules/sipp/examples/sipp-scenarios/uas_answer.xml (106)
A src/modules/sipp/sipp_mod.c (419)
A src/modules/sipp/sipp_prom.c (141)
A src/modules/sipp/sipp_prom.h (45)
A src/modules/sipp/sipp_rpc.c (1058)
A src/modules/sipp/sipp_rpc.h (33)
A src/modules/sipp/sipp_test.c (1962)
A src/modules/sipp/sipp_test.h (278)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4581.patchhttps://github.com/kamailio/kamailio/pull/4581.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4581
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4581(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
- [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 #XXXX (replace XXXX with an open issue number)
#### Description
Previously when doing DNS NAPTR lookup, incorrect detection of first lookup was causing only the first NAPTR entry to be checked.
This has been fixed by storing NAPTR entry information in dns_srv_handle, allowing us to correctly differentiate between first lookup and following lookups.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4577
-- Commit Summary --
* core: dns - Fix lookup of multiple NAPTR entries
-- File Changes --
M src/core/dns_cache.c (16)
M src/core/dns_cache.h (30)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4577.patchhttps://github.com/kamailio/kamailio/pull/4577.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4577
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4577(a)github.com>
bferreirq created an issue (kamailio/kamailio#4565)
### Description
When using `publ_cache = 2` (memory-only mode) with the `pua_json` module to publish MWI (message-summary) events, multiple presentity entries with the **same etag** accumulate in memory instead of being replaced.
This causes **inconsistent NOTIFY messages** to be sent to subscribers: sometimes the most recent state (correct), sometimes an obsolete state (incorrect).
According to RFC 3903, when a PUBLISH with an existing etag is received, it should **replace** the previous entry, not create a duplicate.
### Troubleshooting
#### Reproduction
1. Configure Kamailio with:
- `publ_cache = 2` (memory-only mode)
- `subs_db_mode = 0` (memory-only mode)
- External application publishes MWI updates via HTTP to `pua_json_publish()`
2. Publish multiple MWI updates for the same user over several days:
```json
POST /sip_not/ HTTP/1.1
{
"Event-Package": "message-summary",
"From": "sip:user@domain.com",
"Messages-New": 3,
"Messages-Saved": 0,
"Expires": "63072000",
"Call-ID": "fake_call_id"
}
```
3. Later, publish a new state:
```json
{
"Messages-New": 0,
"Messages-Saved": 0,
"Call-ID": "fake_call_id"
}
```
4. Check the cache:
```bash
kamcmd presence.presentity_show full user domain.com
```
**Result**: Multiple entries with the same `etag: fake_call_id` coexist instead of the newer one replacing the older ones.
#### Debugging Data
Cache inspection shows 3 duplicate entries for the same user with identical etag:
```
Entry 1 (Most recent):
user: user
domain: domain.com
event: message-summary
etag: fake_call_id
expires: 1832235420
received_time: 1769163420 (Jan 23, 2026 11:03)
priority: 0
body: Voice-Message: 0/0 (0/0)
hashid: -883060685
Entry 2 (Obsolete):
user: user
domain: domain.com
event: message-summary
etag: fake_call_id
expires: 1831959900
received_time: 1768887900 (Jan 20, 2026 04:05)
priority: 0
body: Voice-Message: 4/0 (0/0)
hashid: -883060685
Entry 3 (Obsolete):
user: user
domain: domain.com
event: message-summary
etag: fake_call_id
expires: 1831908632
received_time: 1768836632 (Jan 19, 2026 14:17)
priority: 0
body: Voice-Message: 3/0 (0/0)
hashid: -883060685
```
All three entries share:
- Same `etag: fake_call_id`
- Same `hashid: -883060685`
- Different `received_time` and body content
#### Log Messages
No errors in logs. The publications are accepted successfully, but old entries are not removed.
#### SIP Traffic
When a SUBSCRIBE is received, the NOTIFY sometimes contains **obsolete values** from older cache entries instead of the most recent one
Example NOTIFY with obsolete value:
```
NOTIFY sip:user@x.x.x.x SIP/2.0
Event: message-summary
Subscription-State: terminated;reason=timeout
Content-Type: application/simple-message-summary
Messages-Waiting: yes
Message-Account: sip:user@domain.com
Voice-Message: 3/0 (0/0)
```
### Possible Solutions
**Workarounds attempted:**
- ✅ `kamcmd presence.cleanup` → No effect (entries have future expires)
- ✅ `kamcmd presence.refreshWatchers` → No effect (entries not removed)
- ❌ No RPC command found to remove specific presentity entries
**Only solution found:** Restart Kamailio (clears memory cache entirely).
**Questions:**
1. **Is this a bug?** Should presentities with the same etag be replaced instead of accumulated?
2. **Selection logic**: With `retrieve_order = 0` (default), documentation states "presentity records are retrieved by received_time order". When multiple entries exist:
- Which one is selected for NOTIFY?
- Is it guaranteed to be the most recent (highest received_time)?
- Why do we sometimes get obsolete entries in NOTIFY?
3. **Cleanup**: Is there any RPC command to:
- Remove a specific presentity entry by `ruid`?
- Force removal of obsolete entries with the same etag?
- Flush presentity cache for a specific user without restarting?
4. **Configuration recommendation**: Should we use `publ_cache = 0` when an external application publishes via `pua_json`?
### Additional Information
**Kamailio Version**:
```
version: kamailio 5.7.3 (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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
```
**Operating System**:
```
Debian GNU/Linux 10 (buster)
Linux 4.19.0-21-amd64 #1 SMP Debian 4.19.249-2 (2022-06-30) x86_64 GNU/Linux
```
**Modules loaded**:
```
kamailio-presence-modules:amd64 5.7.3+bpo10
kamailio-json-modules:amd64 5.7.3+bpo10
```
**Configuration excerpt**:
```cfg
modparam("presence", "subs_db_mode", 0)
modparam("presence", "publ_cache", 2)
modparam("presence", "expires_offset", 10)
modparam("presence", "max_expires", 86400)
modparam("presence", "min_expires", 30)
modparam("presence", "pres_htable_size", 20)
modparam("presence", "subs_htable_size", 20)
modparam("presence_mwi", "default_expires", 3600)
event_route[xhttp:request] {
xhttp_reply("200", "OK", "text/html","<html><body>OK</body></html>");
$var(x) = pua_json_publish($rb);
}
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4565
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4565(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>
<!-- 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 -->
- [x] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
Introduced a new parameter: `reloadat=<seconds_value>`, that could be applied individually per hash table.
At each `seconds_value` the hash table will be reloaded automatically.
Tests were done, and the timer logic and the reloads are working fine.
`rpc.reload` still works just fine.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4560
-- Commit Summary --
* htable: add reloadat param
-- File Changes --
M src/modules/htable/doc/htable_admin.xml (27)
M src/modules/htable/ht_api.c (107)
M src/modules/htable/ht_api.h (9)
M src/modules/htable/htable.c (71)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4560.patchhttps://github.com/kamailio/kamailio/pull/4560.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4560
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4560(a)github.com>
#### 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 -->
- [ ] PR should be backported to stable branches
- [X] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
Variable rtp_inst_pvar stores URI which can be IP address and port or DNS name or port. Description is getting false sense that this variable holds IP address received by RTPengine NG protocol.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4558
-- Commit Summary --
* rtpengine: update documentation for rtp_inst_pvar variable
-- File Changes --
M src/modules/rtpengine/doc/rtpengine_admin.xml (4)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4558.patchhttps://github.com/kamailio/kamailio/pull/4558.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4558
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4558(a)github.com>
miconda created an issue (kamailio/kamailio#4578)
At least Debian/Ubuntu ship many versions of lua and liblua, like 5.1, 5.2, 5.3 and 5.4. So far the package including app_lua compiled with liblua5.1, @linuxmaniac plans to switch to a newer version, but I am thinking that maybe we can ship app_lua many times, to offer a variant linked with each lualib version. The app_lua module can be compiled with any of those available in Debian/Ubuntu.
Therefore I am starting this issue more like a discussion to see what can be done. Maybe @xkaraman can comment if cmake could cover easier such needs. We can provide the internal module name as a compile option (i.e., `-DMOD_NAME='"app_lua"'` or `-DMOD_NAME='"app_lua52"'`), then the output object file should have similar name (e.g., `app_lua.so` or `app_lua52.so`).
I see a combination of two input values, the name of the module and the library version to compile with. I would say, linking with the latest stable library version should result in the `app_lua.so`, the other variants should be with version number (e.g., `app_lua52.so`). The question is also if @linuxmaniac (and the other packagers) could leverage such mechanism, to compile a module many times and package the results in different packages, because they have different library requirements/dependencies.
There is a similar case with `tls` and `tlsa`, which is done a bit awkward, by including tls files completely inside tlsa files. I won't go the same path, the need for tlsa was required by the instability of latest libssl at that moment. Here, if we cannot find a flexible and easy enough solution, we should probably just go with linking against latest stable liblua.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4578
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4578(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>
joelsdc created an issue (kamailio/kamailio#4574)
## Description
Given the following [xhttp_prom_tags](https://www.kamailio.org/docs/modules/stable/modules/xhttp… config:
```
modparam("xhttp_prom", "xhttp_prom_uptime_stat", 1)
modparam("xhttp_prom", "xhttp_prom_tags", "hostname=\"kamailio-test\"");
modparam("xhttp_prom", "prom_counter", "name=kamailio_test_metric_one; label=label1:label2:label3");
modparam("xhttp_prom", "prom_counter", "name=kamailio_test_metric_two; label=label1:label2");
modparam("xhttp_prom", "xhttp_prom_stats", "all")
modparam("xhttp_prom", "xhttp_prom_pkg_stats", 1)
```
When you scrape the metrics endpoint, the custom metrics (in this case: `kamailio_test_metric_one` and `kamailio_test_metric_two`) don't include the tags configured in **xhttp_prom_tags**.
Example:
```
kamailio_test_metric_one{label1="XXX", label2="YYY", label3="ZZZ"} 3 1769758020393
kamailio_test_metric_two{label1="XXX", label2="YYY"} 68 1769758020393
kamailio_core_drop_requests{hostname="kamailio-test"} 177 1769758020393
kamailio_core_err_requests{hostname="kamailio-test"} 0 1769758020393
kamailio_core_fwd_requests{hostname="kamailio-test"} 0 1769758020393
```
Expected:
```
kamailio_test_metric_one{hostname="kamailio-test", label1="XXX", label2="YYY", label3="ZZZ"} 3 1769758020393
kamailio_test_metric_two{hostname="kamailio-test", label1="XXX", label2="YYY"} 68 1769758020393
kamailio_core_drop_requests{hostname="kamailio-test"} 177 1769758020393
kamailio_core_err_requests{hostname="kamailio-test"} 0 1769758020393
kamailio_core_fwd_requests{hostname="kamailio-test"} 0 1769758020393
```
## Troubleshooting
## Reproduction
Load xhttp_prom.
Configure:
```
modparam("xhttp_prom", "xhttp_prom_uptime_stat", 1)
modparam("xhttp_prom", "xhttp_prom_tags", "hostname=\"kamailio-test\"");
modparam("xhttp_prom", "prom_counter", "name=kamailio_test_metric_one; label=label1:label2:label3");
modparam("xhttp_prom", "prom_counter", "name=kamailio_test_metric_two; label=label1:label2");
modparam("xhttp_prom", "xhttp_prom_stats", "all")
modparam("xhttp_prom", "xhttp_prom_pkg_stats", 1)
```
And the minimal config in http event_route:
```
event_route[xhttp:request] {
# Prometheus metrics endpoint
if (prom_check_uri()) {
prom_dispatch();
exit;
}
xhttp_reply("404", "Not found", "text/html", "<html><body>Wrong URL $hu</body></html>");
return;
}
```
Somewhere in the request_route add:
```
prom_counter_inc("kamailio_test_metric_one", "1", "XXX", "YYY", "ZZZ");
prom_counter_inc("kamailio_test_metric_two", "1", "XXX", "YYY");
```
Start Kamailio.
Generate traffic so the counter is incremented.
Fetch `/metrics` (e.g., `curl -s http://<kamailio-ip>:<port>/metrics`).
Observe the labels on the custom metrics.
### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(n/a - config/formatting issue; no crash)
```
### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(n/a - no relevant errors logged)
```
### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(n/a)
```
## Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 6.0.5 (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 with gcc 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`)
-->
```
Linux kamailio-test 6.12.63+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.63-1 (2025-12-30) x86_64 GNU/Linux
Distributor ID: Debian
Description: Debian GNU/Linux 13 (trixie)
Release: 13
Codename: trixie
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4574
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4574(a)github.com>