July 2026 - sr-dev - kamailio.org

[kamailio/kamailio] TOPOS: Feature/add reg pub (PR #4771)
by Harish S 12 Aug '26

12 Aug '26

#### 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] Code is formatted with `clang-format` using the config file `.clang-format` from source code folder - [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  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4771 -- Commit Summary -- * Enhance topos module to support REGISTER and PUBLISH requests * Fix tps_common.c symlinks in topos_htable and topos_redis -- File Changes -- M src/modules/topos/api.h (3) M src/modules/topos/doc/topos_admin.xml (79) M src/modules/topos/topos_mod.c (42) A src/modules/topos/tps_common.c (181) M src/modules/topos/tps_msg.c (359) M src/modules/topos/tps_storage.c (350) M src/modules/topos/tps_storage.h (14) M src/modules/topos_htable/CMakeLists.txt (3) M src/modules/topos_htable/Makefile (1) M src/modules/topos_htable/topos_htable_mod.c (1) M src/modules/topos_htable/topos_htable_storage.c (444) M src/modules/topos_htable/topos_htable_storage.h (2) A src/modules/topos_htable/tps_common.c (1) M src/modules/topos_redis/CMakeLists.txt (3) M src/modules/topos_redis/Makefile (1) M src/modules/topos_redis/topos_redis_mod.c (1) M src/modules/topos_redis/topos_redis_storage.c (372) M src/modules/topos_redis/topos_redis_storage.h (2) A src/modules/topos_redis/tps_common.c (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4771.patch https://github.com/kamailio/kamailio/pull/4771.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4771 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4771(a)github.com>

4 6

[kamailio/kamailio] sqlops: Add docs regarding queries and where clauses (PR #4853)
by Xenofon Karamanos 11 Aug '26

11 Aug '26

#### 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) - [ ] LLM/AI Coding Assistants were involved in creating the C code or other included content - [ ] Code is formatted with `clang-format` using the config file `.clang-format` from source code folder - [ ] 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  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4853 -- Commit Summary -- * sqlops: Add docs regarding queries and where clauses -- File Changes -- M src/modules/sqlops/doc/sqlops_admin.xml (41) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4853.patch https://github.com/kamailio/kamailio/pull/4853.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4853 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4853(a)github.com>

3 7

[kamailio/kamailio] db_redis won't build with hiredis_cluster (Issue #4773)
by srsrsr59 11 Aug '26

11 Aug '26

srsrsr59 created an issue (kamailio/kamailio#4773) db_redis won't build with redis cluster support. Tried both towards latest release (6.1.3) and master branch. ``` [9/9] RUN cd /tmp/src/modules/db_redis && export WITH_HIREDIS_CLUSTER && make Q=0: 0.250 config.mak included 0.420 make -wC ../.. cfg-defs 0.421 make[1]: Entering directory '/tmp/src' 0.422 normal Makefile.defs exec 0.452 target architecture <x86_64>, host architecture <x86_64> 0.482 making config... 0.489 make[1]: Leaving directory '/tmp/src' 0.491 config.mak included 0.577 make: --libs: No such file or directory 0.591 make: --libs: No such file or directory 0.635 config.mak included 0.725 make: --libs: No such file or directory 0.742 make: --libs: No such file or directory 0.780 gcc -fPIC -DPIC -g -pthread -funroll-loops -Wcast-align -m64 -minline-all-stringops -falign-loops -ftree-vectorize -fno-strict-overflow -mtune=generic -DKSR_PTHREAD_MUTEX_SHARED -Wall -DNAME='"kamailio"' -DVERSION='"6.1.3"' -DARCH='"x86_64"' -DOS='linux_' -DOS_QUOTED='"linux"' -DCOMPILER='"gcc 14.2.0"' -D__CPU_x86_64 -D__OS_linux -DVERSIONVAL=6001003 -DCFG_DIR='"/usr/local/etc/kamailio/"' -DSHARE_DIR='"/usr/local/share/kamailio/"' -DRUN_DIR='"/var/run/kamailio/"' -DPKG_MALLOC -DSHM_MMAP -DDNS_IP_HACK -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLOCKLIST -DUSE_NAPTR -DMEM_JOIN_FREE -DF_MALLOC -DQ_MALLOC -DTLSF_MALLOC -DDBG_SR_MEMORY -DUSE_TLS -DTLS_HOOKS -DUSE_CORE_STATS -DSTATISTICS -DMALLOC_STATS -DUSE_SCTP -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_SCHED_SETSCHEDULER -DHAVE_IP_MREQN -DUSE_RAW_SOCKS -DHAVE_EPOLL -DHAVE_SIGIO_RT -DSIGINFO64_WORKAROUND -DUSE_FUTEX -DHAVE_SELECT -I/usr/include/hiredis -D_FILE_OFFSET_BITS=64 -DWITH_SSL -DWITH_HIREDIS_CLUSTER -I/usr/local/include/hiredis_cluster -D_FILE_OFFSET_BITS=64 -DWITH_SSL -DMOD_NAME='"db_redis"' -DMOD_NAMEID='db_redis' -c db_redis_mod.c -o db_redis_mod.o -MMD -MP 0.870 In file included from redis_connection.h:29, 0.870 from redis_table.h:29, 0.870 from db_redis_mod.c:32: 0.870 /usr/local/include/hiredis_cluster/hircluster.h:50:27: error: expected identifier before numeric constant 0.870 50 | #define REDIS_ROLE_MASTER 1 0.870 | ^ 0.870 redis_sentinels.h:48:9: note: in expansion of macro 'REDIS_ROLE_MASTER' 0.870 48 | REDIS_ROLE_MASTER, 0.870 | ^~~~~~~~~~~~~~~~~ 0.880 make: *** [../../Makefile.rules:100: db_redis_mod.o] Error 1 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4773 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4773(a)github.com>

4 13

[kamailio/kamailio] With "track_cseq_updates 1" kamailio cannot match incoming responses (Issue #4837)
by evgoley 11 Aug '26

11 Aug '26

evgoley created an issue (kamailio/kamailio#4837)  ### Description For authentication with the upstream provider, I use the “uac” module with the ‘dialog’ module parameter "track_cseq_updates 1". After receiving a 401 response, Kamailio sends an ACK and then sends an INVITE with an increased CSeq value and a new “branch” value. Kamailio cannot map the subsequent responses from the provider to any current transaction. ### Troubleshooting #### Reproduction Using track_cseq_updates parameter in the Dialog module, the CSeq offset should be automatically tracked if the UAC module is performing authentication. #### Log Messages Provided as attachment. #### SIP Traffic Provided as attachment. 91.195.100.29:2020 84.22.140.7.5060 ─────┬───── ──────┬──────── │ INVITE (SDP) Cseq:1 │ branch=z9hG4bKb18c.c3cb1d18ecf9ae57bb12b723e4dfd0dc.0 │ ───────────> │ │ 401 Unauthorized Cseq:1 │ │ <─────────── │ │ ACK │ │ ───────--────> │ │ │ │ INVITE (SDP) Cseq:2 │ │ ──────────--─> │ branch=z9hG4bKb18c.c3cb1d18ecf9ae57bb12b723e4dfd0dc.1.cs117883881 │ 100 Trying Cseq:2 │ │ <────────────────────────── │ │ INVITE (SDP) Cseq:2 │ branch=z9hG4bKb18c.c3cb1d18ecf9ae57bb12b723e4dfd0dc.1.cs117883881 │──────────────────────────>> │ │ 100 Trying Cseq:2 │ │ <────────────────────────── │ │ 180 Ringing │ │ <────────────────────────── │ │ │ ### Possible Solutions ### Additional Information - [ ] LLM/AI Assistants were involved in discovery, analysis or submission of the issue - [ V] It happened in a production deployment - [ ] It happened in a testing or development deployment - [ ] Testing or fuzzing tools were used to generate SIP traffic when it happened * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.6 (x86_64/linux) c718a7 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. id: c718a7 compiled on 05:41:25 Sep 1 2025 with gcc 11.5.0 ``` * **Operating System**: ``` uname -a inux sip-gateway-client-gera 5.14.0-570.33.2.el9_6.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Aug 15 17:42:51 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux ``` ``` cat /etc/redhat-release Rocky Linux release 9.6 (Blue Onyx) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4837 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4837(a)github.com>

2 10

[kamailio/kamailio] TCP threaded receiver mode - v2 (PR #4825)
by space88man 11 Aug '26

11 Aug '26

#### 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] LLM/AI Coding Assistants were involved in creating the C code or other included content - [X]Code is formatted with `clang-format` using the config file `.clang-format` from source code folder - [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 ## Threaded TCP receiver (`tcp_main_threads = 2`) This PR adds a threaded TCP receiver — the TCP counterpart to the UDP `udp_receiver_mode = 1` setting. Unlike UDP, this mode also confines TCP writes to a single process. The mode is selected with `tcp_main_threads`: - `0` — classic multi-process TCP network I/O and TLS (unchanged). - `1` — multi-process TCP network I/O, but the read for TLS and all TLS run in a single process. This was previously `tcp_main_threads > 0`. - `2` (new) — all TCP network I/O and all TLS run in `PROC_TCP_MAIN`. ### What changes in mode 2 Transport is separated from SIP message handling. `PROC_TCP_MAIN` is the only process that holds network sockets, so sockets are no longer passed between processes with `sendmsg`/`SCM_RIGHTS`. That removes the fd book-keeping and the borrow/release handshake around TCP sockets. - Writes are always asynchronous. A worker never writes to a socket; it hands the payload to `PROC_TCP_MAIN` via `CONN_WRITE_REQ`. - Outbound connections with no existing `tcp_connection_t` are opened in `PROC_TCP_MAIN` (via `CONN_CONNECT_REQ`) instead of in a worker. - `PROC_TCP_MAIN` runs a thread pool for socket reads and async writes. The pool size is set with `tcp_reactor_threads` (default 8). ### Notes for reviewers - The `src/core` commits are not squashed, so each step is a smaller read. - HEP/HEP3, WS/WSS and MSRP are not wired up in the early commits; support is restored later, once plain TCP/TLS was tested. - `pkg_malloc` is lock-free and assumes one thread per process, which mode 2 breaks. If Kamailio is built against the system `malloc` (glibc, musl, …) this is a non-issue, since those are thread-safe. With Kamailio's own allocators, the `pkg` path is serialized inside `PROC_TCP_MAIN`; that serialization is confined to `PROC_TCP_MAIN` and touches nothing else. - Modes 0 and 1 are untouched. Every new code path is gated on `tcp_main_threads = 2`. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4825 -- Commit Summary -- * core: tcp reactor - TCP threaded receiver mode * core: tcp reactor - dispatch SIP messages to worker * core: tcp reactor - PROC_TCP_MAIN thread pool and plain-TCP reads * core: tcp reactor - offload writes and TLS to the pool * core: tcp reactor - outbound connect and partial-read reaper * core: tcp reactor - route HEP3 to hep3_process_msg * core: tcp reactor - route MSRP to msrp_process_msg * msrp: update to handle TCP mode = 2 * core: tcp reactor - WS/WSS support and reader-pool thread-safety * websocket: support the TCP mode 2 * core: tcp reactor - configure number of threads -- File Changes -- M cmake/lock_methods.cmake (36) M src/core/cfg.lex (2) M src/core/cfg.y (3) M src/core/globals.h (1) A src/core/tcp_cond.c (159) A src/core/tcp_cond.h (66) M src/core/tcp_conn.h (33) M src/core/tcp_main.c (1337) M src/core/tcp_mtops.c (57) M src/core/tcp_mtops.h (4) A src/core/tcp_reactor.c (79) A src/core/tcp_reactor.h (159) A src/core/tcp_reactor_mem.c (172) A src/core/tcp_reactor_mem.h (76) M src/core/tcp_read.c (118) M src/core/tcp_read.h (3) M src/core/tcp_server.h (6) M src/modules/msrp/msrp_cmap.c (7) M src/modules/websocket/ws_conn.c (8) M src/modules/websocket/ws_frame.c (33) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4825.patch https://github.com/kamailio/kamailio/pull/4825.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4825 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4825(a)github.com>

1 28

Dinosaur Game: A Simple Offline Classic That Became a Global Icon
by oliverrichard1903＠gmail.com 10 Aug '26

10 Aug '26

The Dinosaur Game, often called the “Chrome Dino” or “T-Rex Runner,” is one of the most recognizable browser mini-games in the world. Originally created as a playful way to entertain users when their internet connection dropped, it quickly evolved into a beloved classic enjoyed by millions—even by people who do have internet. Its simplicity, charm, and addictive gameplay have turned a tiny offline feature into a global gaming phenomenon. A Game Born From an Internet Error The Dinosaur Game first appears when Google Chrome users lose their internet connection. Instead of just showing a dull error message, Chrome displays a tiny pixelated T-Rex standing in the desert. Pressing the spacebar brings the dinosaur to life, launching players into an endless runner challenge that offers surprisingly tense and exciting gameplay. What began as a joke among Chrome developers soon became an iconic part of the browser experience. Today, many players deliberately turn off their Wi-Fi just to enjoy a quick run. Simple but Addictive Gameplay The brilliance of the Dinosaur Game lies in its simplicity. There are no complicated controls—players only jump and duck to avoid obstacles. Cacti, birds, and increasing speed create a progressively harder challenge that tests reflexes and focus. This minimalist approach is what makes the game so addictive. Every attempt pushes you to survive just a little longer, to beat your previous high score, or to compete with friends. With only one objective—run as far as you can—the game becomes a pure test of skill. The Endless Challenge As the game continues, the pace becomes faster and more intense. The desert backdrop shifts between day and night, adding variety to the otherwise simple environment. Birds fly at different heights, forcing players to time their jumps and ducks perfectly. One mistake ends the run instantly, creating high stakes even in such a small game. This constant rise in difficulty is what keeps players coming back. The game feels easy at first but quickly transforms into a fast-paced challenge that requires full concentration. https://dinosaur-game.io

4 3

[kamailio/kamailio] github: Actions failing due to shallow source copy (Issue #4848)
by Xenofon Karamanos 10 Aug '26

10 Aug '26

xkaraman created an issue (kamailio/kamailio#4848)  ### Description Action like check-cmake-format or check-commit fail due to shallow state changed: ``` fatal: shallow file has changed since we read it Error: Process completed with exit code 128. ``` #### Reproduction Randomly on github actions ### Possible Solutions SUGGESTED BY THE COPILOT AI. I have not tested it in any way! Add `fetch-depth: 0` when checkout source in github action workflow. ### Additional Information - [x] LLM/AI Assistants were involved in discovery, analysis or submission of the issue - [ ] It happened in a production deployment - [ ] It happened in a testing or development deployment - [ ] Testing or fuzzing tools were used to generate SIP traffic when it happened ### GITHUB COPILIT when asked why this particular fail happened. Copied as is from the conversation. ``` Root cause: the failure is in the check-cmake-format job and is caused by Git fetch state corruption/race in a shallow clone, not by your CMake formatting itself. From the log: fatal: shallow file has changed since we read it exit code 128 This aligns with the workflow design in .github/workflows/pull_request.yml where the job does two checkouts (actions/ and source/) and then runs a script that likely performs additional fetch operations using FETCH_DEPTH. With shallow history, this can trigger the shallow metadata conflict. Source: Workflow file: https://github.com/kamailio/kamailio/blob/a9fa97b56370ed89852f66f5a55db4c7f… Recommended fix Make the source checkout full-depth (or at least avoid shallow behavior) for this job, so later fetches do not mutate .git/shallow unexpectedly. Suggested patch YAML # .github/workflows/pull_request.yml check-cmake-format: runs-on: ubuntu-latest needs: depth-value permissions: contents: read steps: - name: Check out scripts folder to the runner uses: actions/checkout@v7 with: ref: master path: actions sparse-checkout: | .github/scripts/check-cmake-format.sh sparse-checkout-cone-mode: false - name: Check out the repository to the runner uses: actions/checkout@v7 with: path: source ref: ${{ github.event.pull_request.head.sha }} fetch-depth: 0 # <-- important - uses: awalsh128/cache-apt-pkgs-action(a)v1.6.3 with: packages: cmake-format - name: Run scripts/check-cmake-format.sh run: ${{ github.workspace }}/actions/.github/scripts/check-cmake-format.sh working-directory: ${{ github.workspace }}/source env: ref: ${{ github.event.pull_request.head.sha }} FETCH_DEPTH: ${{ needs.depth-value.outputs.pr_depth }} Optional hardening If you want to keep shallow behavior, modify check-cmake-format.sh to avoid any extra git fetch --depth ... when running in CI, or always unshallow first (git fetch --unshallow || true) before depth-limited fetch logic. But the safest CI fix is fetch-depth: 0 on the source checkout. ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4848 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4848(a)github.com>

3 5

[kamailio/kamailio] msg_apply_changes_mode / MSG_APPLY_CHANGES breaks serial forking after a 302 (Issue #4844)
by descartin 10 Aug '26

10 Aug '26

descartin created an issue (kamailio/kamailio#4844)  ### Description Hi, This is feedback regarding the new `t_msg_apply_changes()` functionality for `branch_route`. We are running: ```text Kamailio 6.1.2 (x86_64/Linux) ``` Our goal is to use `t_msg_apply_changes()` inside a `branch_route` to rebuild an INVITE body as `multipart/mixed`, containing SDP and binary ISUP. The relevant call flow is: 1. An incoming INVITE is received. 2. The transaction is explicitly created early in `request_route` using `t_newtran()`. 3. The first branch is relayed to an external routing service. 4. The routing service replies with `302`. 5. `failure_route` selects a B2B and calls `t_relay()` again, adding a new branch to the same transaction. 6. `branch_route[B2B_BRANCH]` should build the multipart SDP+ISUP body. The configuration can be simplified as follows: ```kamailio request_route { # Tested here for the per-message alternative: # msg_iflag_set("MSG_APPLY_CHANGES"); if (!t_check_trans()) { if (!t_newtran()) { send_reply("500", "Unable to create transaction"); exit; } } t_on_branch("SRV1_BRANCH"); t_on_failure("SRV1_FAILED"); if (!t_relay()) { ... } } failure_route[SRV1_FAILED] { if (t_check_status("302")) { # Parse the routing result and select the B2B ... t_on_branch("B2B_BRANCH"); t_on_failure("B2B_FAILED"); if (!t_relay()) { xlog("L_ERR", "Unable to relay INVITE\n"); } exit; } } branch_route[B2B_BRANCH] { route(REMOVE_HEADERS); set_body_multipart(); t_msg_apply_changes(); append_body_part( "$avp(s:sipt_sdp_final)", "application/sdp", "session;handling=required" ); t_msg_apply_changes(); append_body_part( "$avp(s:isup_raw_part)", "application/isup;version=ttc93-bbix;base=ttc93", "signal;handling=required" ); t_msg_apply_changes(); # Kept after t_msg_apply_changes(), as recommended record_route(); route(APPEND_HEADERS); } ``` The intermediate `t_msg_apply_changes()` calls are needed because each following multipart operation needs to see the Content-Type and boundary generated by the previous operation. ### Test 1: `msg_apply_changes_mode = 1` With: ```kamailio msg_apply_changes_mode = 1 ``` the initial branch is sent successfully and the routing service replies with `302`. However, the second `t_relay()` fails before `B2B_BRANCH` is executed: ```text INFO: SRV1 Status 302 INFO: Sending call to B2b Server 10.100.10.214:5060 INFO: call time processed ----> 22704 microseg ERROR: <core> [core/sip_msg_clone.c:1010]: sip_msg_copy(): invalid output buffer ERROR: tm [t_fwd.c:1830]: t_forward_nonack(): failure to add branches ERROR: tm [tm.c:1887]: _w_t_relay_to(): t_forward_noack failed INFO: Unable to relay INVITE to <null> ``` Disabling `msg_apply_changes_mode` allows the second serial branch to be created normally. The same failure occurs with `msg_apply_changes_mode=1` even when `t_msg_apply_changes()` is not explicitly called. Therefore, the problem appears to happen in the automatic/local message-copy path enabled by the global parameter, before the branch route is entered. The full debug log shows that the first copy succeeds: ```text 2(21825) DEBUG: tm [t_lookup.c:1897]: t_newtran(): ... 2(21825) DEBUG: <core> [core/msg_translator.c:3670]: sip_msg_update_buffer(): SIP message content updated - reparsing 2(21825) DEBUG: tm [sip_msg.c:97]: save_msg_lumps(): lumps have been already cloned 2(21825) DEBUG: <core> [core/sip_msg_clone.c:1039]: sip_msg_copy(): SIP message content copied - reparsing ``` The `302` is then processed by another worker, and the second copy fails: ```text 8(21831) INFO: SRV1 Status 302 8(21831) ERROR: <core> [core/sip_msg_clone.c:1010]: sip_msg_copy(): invalid output buffer ``` ### Test 2: `MSG_APPLY_CHANGES` set after `t_newtran()` With the global mode disabled, we initially called: ```kamailio msg_iflag_set("MSG_APPLY_CHANGES"); ``` after the explicit `t_newtran()` but before the first `t_relay()`. The serial branch was created and `B2B_BRANCH` was executed, but every `t_msg_apply_changes()` returned: ```text ERROR: tm [tm.c:3423]: w_t_msg_apply_changes(): the function cannot be used ERROR: textops [textops.c:3214]: ki_append_multibody_cd(): Cannot get boundary. Is body multipart? ``` We understand that setting the flag after transaction creation is too late. The multipart boundary errors are secondary because the preceding `set_body_multipart()` changes were not applied. ### Test 3: `MSG_APPLY_CHANGES` set before `t_newtran()` We then moved the flag before transaction creation: ```kamailio request_route { msg_iflag_set("MSG_APPLY_CHANGES"); if (!t_check_trans()) { if (!t_newtran()) { ... } } ... } ``` In this case, the result was the same as with the global mode: the first relay succeeded, but the second relay after the `302` failed with: ```text ERROR: <core> [core/sip_msg_clone.c:1010]: sip_msg_copy(): invalid output buffer ERROR: tm [t_fwd.c:1830]: t_forward_nonack(): failure to add branches ERROR: tm [tm.c:1887]: _w_t_relay_to(): t_forward_noack failed ``` Therefore, the per-message flag does not avoid the problem: - Set after `t_newtran()`, it does not enable `t_msg_apply_changes()`. - Set before `t_newtran()`, it activates the same failing copy path as `msg_apply_changes_mode=1`. We also tried: - Moving `record_route()` after all `t_msg_apply_changes()` calls. - Calling `t_save_lumps()` before the initial relay. Neither changed the result. ### Possible source-level cause While correlating the debug log with the Kamailio 6.1.2 source, we noticed a possible missing initialization in [`[prepare_new_uac()](https://github.com/kamailio/kamailio/blob/6.1.2/src/modules/tm/t_fwd.c#L359-L367)`](https://github.com/kamailio/kamailio/blob/6.1.2/src/modules/tm/t_fwd.c#L359-L367): ```c char l_buf[BUF_SIZE]; sip_msg_t l_req; ... if((ksr_msg_apply_changes_mode == 1) || (i_req->msg_flags & FL_MSG_APPLY_CHANGES)) { l_copy = 1; } if(l_copy == 1) { memset(&l_req, 0, sizeof(sip_msg_t)); l_req.buf = l_buf; l_buf[0] = '\0'; if(sip_msg_copy(i_req, &l_req, 0) < 0) { ... } } ``` `l_req.buf` is initialized, but `l_req.buf_size` remains zero. [`[sip_msg_copy()](https://github.com/kamailio/kamailio/blob/6.1.2/src/core/sip_msg_clone.c#L1002-L1011)`](https://github.com/kamailio/kamailio/blob/6.1.2/src/core/sip_msg_clone.c#L1002-L1011) performs the following check: ```c if(omsg->buf == NULL || imsg->buf_size > omsg->buf_size) { LM_ERR("invalid output buffer\n"); return -1; } ``` The initially received request is zero-initialized and has `buf_size == 0`, so the first relay can pass this comparison. During failure-route processing, however, the request is cloned from the transaction request. The shared-memory clone sets: ```c new_msg->buf_size = new_msg->len + ksr_msg_clone_extra_size; ``` Therefore, during the second serial relay, `sip_msg_copy()` effectively compares: ```text imsg->buf_size > l_req.buf_size non-zero > 0 ``` This appears to explain exactly why the first branch works while the branch created after the `302` fails before entering `B2B_BRANCH`. Would the intended initialization be something like the following? ```c memset(&l_req, 0, sizeof(sip_msg_t)); l_req.buf = l_buf; l_req.buf_size = sizeof(l_buf); l_buf[0] = '\0'; ``` The same missing `buf_size` initialization is also present in the 6.1.3 source and in the current `6.1`/`master` branches at the time of writing. Our current workaround is to leave both mechanisms disabled and build the complete multipart body in a single `set_body_hex()` operation, without using intermediate `t_msg_apply_changes()` calls. Serial forking then works correctly. Could you please confirm: 1. Whether `t_msg_apply_changes()` is intended to work in a branch created from `failure_route` during serial forking. 2. Whether the missing `l_req.buf_size` initialization is the cause of this failure. 3. Whether setting `l_req.buf_size = sizeof(l_buf)` would be the appropriate fix. We can test a patch and provide the complete sanitized configuration, SIP trace and full debug log if useful. Thanks. David Escartín ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information - [x ] LLM/AI Assistants were involved in discovery, analysis or submission of the issue - [ ] It happened in a production deployment - [x ] It happened in a testing or development deployment - [x ] Testing or fuzzing tools were used to generate SIP traffic when it happened * **Kamailio Version** - output of `kamailio -v` ``` (version: kamailio 6.1.2 (x86_64/linux) 1b2dad-dirty ``` * **Operating System**:  ``` centos 7 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4844 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4844(a)github.com>

3 3

[kamailio/kamailio] adjust default tls.cfg (Issue #4810)
by sergey-safarov 10 Aug '26

10 Aug '26

sergey-safarov created an issue (kamailio/kamailio#4810) ### Description When kamailio installed to folder other then `/usr/local`, then required adjust `tls.cfg`. Example when use rpm packaging, then config local in `/etc/kamailio` folder but tls.cfg still use `/usr/local`. ```sh root@nout:/etc/kamailio# kamailio -D -E /etc/kamailio/kamailio.cfg Listening on udp: 192.168.0.62:5060 tcp: 192.168.0.62:5060 Aliases: tcp: testy.localdomain:5060 udp: testy.localdomain:5060 WARNING: no fork mode 0(156721) INFO: <core> [core/tcp_main.c:5316]: init_tcp(): using epoll_lt as the io watch method (auto detected) 0(156721) INFO: <core> [main.c:3335]: main(): current open file limits [soft/hard]: [1024/524288] 0(156721) ERROR: tls [tls_config.c:439]: tls_load_config(): cannot stat config file /usr/local/etc/kamailio/tls.cfg 0(156721) ERROR: <core> [core/sr_module.c:1053]: init_mod(): Error while initializing module tls (/usr/lib64/kamailio/modules/tls.so) ERROR: error while initializing modules 0(156721) INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized ``` ### Troubleshooting N/A #### Reproduction Install rpm packaged Kamailio. Enable `WITH_TLS`. Start using command ```sh kamailio -D -E /etc/kamailio/kamailio.cfg ``` #### Debugging Data N/A #### Log Messages ``` root@nout:/etc/kamailio# kamailio -D -E /etc/kamailio/kamailio.cfg Listening on udp: 192.168.0.62:5060 tcp: 192.168.0.62:5060 Aliases: tcp: testy.localdomain:5060 udp: testy.localdomain:5060 WARNING: no fork mode 0(156721) INFO: <core> [core/tcp_main.c:5316]: init_tcp(): using epoll_lt as the io watch method (auto detected) 0(156721) INFO: <core> [main.c:3335]: main(): current open file limits [soft/hard]: [1024/524288] 0(156721) ERROR: tls [tls_config.c:439]: tls_load_config(): cannot stat config file /usr/local/etc/kamailio/tls.cfg 0(156721) ERROR: <core> [core/sr_module.c:1053]: init_mod(): Error while initializing module tls (/usr/lib64/kamailio/modules/tls.so) ERROR: error while initializing modules 0(156721) INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized ``` #### SIP Traffic N/A ### Possible Solutions Exec `sed` like ```sh sed -e "s|/usr/local/etc/kamailio|${new_path}|" /etc/kamailio/tls.cfg ``` ### Additional Information - [ ] LLM/AI Assistants were involved in discovery, analysis or submission of the issue - [ ] It happened in a production deployment - [ ] It happened in a testing or development deployment - [ ] Testing or fuzzing tools were used to generate SIP traffic when it happened * **Kamailio Version** - output of `kamailio -v` ``` root@nout:/etc/kamailio# kamailio -v version: kamailio 6.1.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, DBG_QM_MALLOC, DBG_F_MALLOC, DBG_TLSF_MALLOC, USE_FUTEX, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED 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 00:00:00 Sep 13 2022 with gcc 15.2.1 ``` * **Operating System**: ``` root@nout:/etc/kamailio# cat /etc/os-release NAME="Fedora Linux" VERSION="43 (Workstation Edition)" RELEASE_TYPE=stable ID=fedora VERSION_ID=43 VERSION_CODENAME="" PRETTY_NAME="Fedora Linux 43 (Workstation Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:43" DEFAULT_HOSTNAME="fedora" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f43/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=43 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=43 SUPPORT_END=2026-12-02 VARIANT="Workstation Edition" VARIANT_ID=workstation ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4810 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4810(a)github.com>

5 15

git:6.1:361c7ac0: xhttp_prom: include global tags in user-defined metrics
by Henning Westerholt 10 Aug '26

10 Aug '26

Module: kamailio Branch: 6.1 Commit: 361c7ac0dc35f9907bcb1e151c0cc6e7971367d8 URL: https://github.com/kamailio/kamailio/commit/361c7ac0dc35f9907bcb1e151c0cc6e… Author: Joel Serrano <joel(a)joelserrano.com> Committer: Henning Westerholt <hw(a)gilawa.com> Date: 2026-03-05T06:37:28Z xhttp_prom: include global tags in user-defined metrics (cherry picked from commit 9f7838561daece724a9fa877cd140f744c81d452) --- Modified: src/modules/xhttp_prom/prom_metric.c --- Diff: https://github.com/kamailio/kamailio/commit/361c7ac0dc35f9907bcb1e151c0cc6e… Patch: https://github.com/kamailio/kamailio/commit/361c7ac0dc35f9907bcb1e151c0cc6e… --- diff --git a/src/modules/xhttp_prom/prom_metric.c b/src/modules/xhttp_prom/prom_metric.c index bd12695847a..31f53f8da60 100644 --- a/src/modules/xhttp_prom/prom_metric.c +++ b/src/modules/xhttp_prom/prom_metric.c @@ -1735,13 +1735,12 @@ static int prom_label_print( goto error; } - if(plval->n_elem == 0) { - /* Nothing to print. */ - return 0; - } - - if(!lb_name || lb_name->n_elem == 0) { - /* Nothing to print. */ + if(plval->n_elem == 0 || !lb_name || lb_name->n_elem == 0) { + /* No metric-specific labels, but print global tags if present. */ + if(prom_body_printf(ctx, "%s", xhttp_prom_tags_braces) == -1) { + LM_ERR("Fail to print\n"); + goto error; + } return 0; } @@ -1773,8 +1772,8 @@ static int prom_label_print( plval_node = plval_node->next; } /* while (lb_name_node && plval_node) */ - /* Close labels. */ - if(prom_body_printf(ctx, "}") == -1) { + /* Append global tags and close labels. */ + if(prom_body_printf(ctx, "%s}", xhttp_prom_tags_comma) == -1) { LM_ERR("Fail to print\n"); goto error; } @@ -1832,8 +1831,8 @@ static int prom_label_print_le( goto error; } - /* Close labels. */ - if(prom_body_printf(ctx, "}") == -1) { + /* Append global tags and close labels. */ + if(prom_body_printf(ctx, "%s}", xhttp_prom_tags_comma) == -1) { LM_ERR("Fail to print\n"); goto error; } @@ -1887,10 +1886,44 @@ static int prom_metric_lvalue_print( goto error; } - /* Print labels */ - if(prom_label_print(ctx, p->lb_name, &pvl->lval)) { - LM_ERR("Fail to print labels\n"); - goto error; + + /* Print labels and append global tags if set */ + int has_labels = + (p->lb_name && p->lb_name->n_elem > 0 && pvl->lval.n_elem > 0); + int has_tags = + (xhttp_prom_tags_comma && xhttp_prom_tags_comma[0] != '\0'); + if(has_labels) { + /* Print user labels, then append global tags if set */ + /* Remove closing brace, append comma, then tags, then close */ + if(prom_body_printf(ctx, "{") == -1) + goto error; + prom_lb_node_t *lb_name_node = p->lb_name->lb; + prom_lb_node_t *plval_node = pvl->lval.lb; + int first = 1; + while(lb_name_node && plval_node) { + if(!first) { + if(prom_body_printf(ctx, ", ") == -1) + goto error; + } + if(prom_body_printf(ctx, "%.*s=\"%.*s\"", lb_name_node->n.len, + lb_name_node->n.s, plval_node->n.len, + plval_node->n.s) + == -1) + goto error; + lb_name_node = lb_name_node->next; + plval_node = plval_node->next; + first = 0; + } + if(has_tags) { + if(prom_body_printf(ctx, "%s", xhttp_prom_tags_comma) == -1) + goto error; + } + if(prom_body_printf(ctx, "}") == -1) + goto error; + } else if(has_tags) { + /* Only global tags */ + if(prom_body_printf(ctx, "{%s}", xhttp_prom_tags) == -1) + goto error; } if(prom_body_printf(ctx, " %" PRIu64, pvl->m.cval) == -1) {

2 1