sr-users June 2026

sr-users@lists.kamailio.org

9 participants
6 discussions

CANCEL on a Ringing Sip Dialog is not relayed
by Johannes Westhuis 12 Jun '26

12 Jun '26

Hi all, I have an issue with Kamailio 6.1.3_bpo13 (installed from http://deb.kamailio.org/kamailio61 trixie/main amd64 Packages) My Kamailio is acting as a proxy and is working very nicely. In certain circumstances (that i am not really able to grasp) a CANCEL request for a ringing call is not relayed as expected. In the log, i can see, that the transaction matching fails. The following messages are exchanged: Client -> INVITE -> Kamailio (Via: SIP/2.0/TCP 192.168.179.124:49196;rport;branch=z9hG4bKPj32D404B5-C596-48B9-93B4-1FA14B659405;alias) Client <- 100 Trying <- Kamailio Client <- 183 Session Progress <- Kamailio Client -> PRACK -> Kamailio Client <- 200 OK (PRACK) <- Kamailio Client <- 180 Ringing <- Kamailio - 7 seconds pause - Client -> CANCEL -> Kamailio (Via: SIP/2.0/TCP 82.xx.xxx.xxx:49196;rport;branch=z9hG4bKPj32D404B5-C596-48B9-93B4-1FA14B659405;alias) The Via headers are send by the client, the second one contains the public ip of the clients nat. The log snippet, that i think is relevant here: 2026-06-05T13:42:19.856635+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG: {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} nathelper [nhelpr_funcs.c:294]: get_contact_uri(): no Contact header 2026-06-05T13:42:19.856649+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG: {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} <core> [core/parser/sdp/sdp.c:865]: parse_sdp(): message body has length zero 2026-06-05T13:42:19.856664+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG: {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} htable [ht_api.c:248]: ht_get_table(): htable found [vtp] 2026-06-05T13:42:19.856679+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG: {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} tm [t_lookup.c:1045]: t_lookupOriginalT(): searching on hash entry 18213 2026-06-05T13:42:19.856696+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG: {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} tm [t_lookup.c:513]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bKPj32D404B5-C596-48B9-93B4-1FA14B659405] 2026-06-05T13:42:19.856710+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG: {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} tm [t_lookup.c:1142]: t_lookupOriginalT(): no CANCEL matching found! 2026-06-05T13:42:19.856725+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG: {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} tm [t_lookup.c:1144]: t_lookupOriginalT(): lookup completed 2026-06-05T13:42:19.856741+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG: {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} tm [tm.c:1327]: ki_t_lookup_cancel_flags(): lookup_original: t_lookupOriginalT returned: (nil) Is the IP in the Via used for matching the transaction? What would be the right thing to do here? Best regards, Johannes

2 2

Postgres connections optimization #4342
by Stephane Savonitto 11 Jun '26

11 Jun '26

Hello, On P-CSCF when running we have 200+ permanent connection to postgres db, even if there is no traffic. Is there a way to manage connections dynamically using a pool like using PgBouncer ? Regards, Stéphane

5 9

Typo in ipops module documentation (detailed_ip_type)
by xf han 09 Jun '26

09 Jun '26

Hello Kamailio community, I was reading the documentation for the ipops module (version 6.1.x) and noticed a minor typo in the description of the detailed_ip_type function. Link to the documentation: https://kamailio.org/docs/modules/6.1.x/modules/ipops.html#ipops.f.detailed… In the description of the returned IPv4 string values, it currently lists: IPv4 - PUBLIC, RIVATE, SHARED, LOOPBACK, LINK-LOCAL, RESERVED, TEST-NET, 6TO4-RELAY, MULTICAST, BROADCAST It seems “PRIVATE” is misspelled as “RIVATE”. It should be corrected to: IPv4 - PUBLIC, PRIVATE, SHARED, LOOPBACK, LINK-LOCAL, RESERVED, TEST-NET, 6TO4-RELAY, MULTICAST, BROADCAST Just wanted to report this small issue so it can be updated in the next documentation build. Best regards, Han

2 1

siptrace HEP-over-TCP: idle TCP connections accumulate on tcp_main, leading to `io_watch_del() invalid fd` CRITICAL
by Floimair Florian 08 Jun '26

08 Jun '26

Hi all, We're running Kamailio 6.1.3 (also seen on 6.1.2) with the `siptrace` module sending HEP duplicates to a single HOMER over TCP. We use the .deb packages from official Kamailio repository on Debian 11 and 13 currently. On every kamailio in our fleet we see idle TCP connections to HOMER accumulate indefinitely on the `tcp_main` process, and on the higher-latency kamailios this eventually triggers a CRITICAL cascade we have to restart out of. Relevant config: tcp_connection_lifetime = 600 tcp_max_connections = 8192 modparam("siptrace", "duplicate_uri", "sip:<homer>:9060;transport=tcp") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "trace_mode", 1) modparam("siptrace", "force_send_sock", "sip:<our_ip>:5060;transport=tcp") `sip_trace()` is called once near the top of `request_route`, after `sanity_check`, with no method filtering — every accepted request is forwarded to HOMER. UDP is unfortunately no longer an option for us (WebRTC/mobile SDP payloads exceed UDP MTU). What we observe: 1. Continuous chronic stream of: ERROR: <core> [core/tcp_main.c:655]: _wbufq_add(): write queue full or timeout ERROR: siptrace [siptrace_hep.c:234]: trace_send_hep3_duplicate(): cannot send hep duplicate message at ~3,000–6,000/hour. 2. `ss` shows ~2,200 ESTAB sockets from one kamailio to HOMER, all owned by the `tcp_main` PID, all `Recv-Q=0 Send-Q=0` with only kernel keepalive timers. Exactly one of them is the actively-used socket; the rest sit idle and are not released. New zombie rate is ~160/hour, so `tcp_max_connections=8192` is hit in ~50 hours. 3. Eventually `tcp_main` emits: CRITICAL: <core> [core/io_wait.h:596]: io_watch_del(): invalid fd 8378, not in [0, 200) followed by a flood of `handle_ser_child(): received CON_ERROR` with rising connection IDs. After this the Kamailio process is impaired and only a restart recovers it. The rate of zombie accumulation, and consequently how often the CRITICAL hits, correlates strongly with RTT to HOMER: kamailios in the same region as HOMER barely leak; kamailios ~100 ms away leak several times faster and are the ones where the cascade recurs. The `_wbufq_add` timeouts being the precursor is consistent with this: at higher RTT, a single TCP socket drains much more slowly, so the per-socket write queue fills faster under the same HEP load. We've done an AI assisted (Claude) source-level reading of the relevant paths in `tcp_main` (`tcp_send`, `_tcpconn_find`, `_wbufq_add`, `tcpconn_main_timeout`). From that reading, the connection lookup and the per-connection timeout cleanup (`tcpconn_main_timeout`, which is what should close idle connections after `tcp_connection_lifetime`) look correct in isolation. It seems the connections must be becoming invisible to that cleanup path somewhere we haven’t tracked down — most plausibly because they end up with `reader_pid != 0` and the reader’s idle handling doesn't release them. But we couldn't confirm this from static reading alone. Has anyone else seen this pattern? Is the model of `reader_pid` holding outbound idle connections indefinitely a known limitation? We have a much longer write-up with `ss` snapshots, per-hour error counts, and the exact lines we walked through in the 6.1 source — happy to share it on-list or open a GitHub issue with it, whichever is preferred. Thanks and best regards, Florian Floimair

1 0

Conflict between TLS module and HTTP_CLIENT causing kamailio 5.8.8 to crash
by Emmanuel BUU 01 Jun '26

01 Jun '26

Hi everybody, We are in the process of migrating from kamailio 4.7 to 5.8. We are hitting a reproducible SIGSEGV when the http_client module performs an HTTPS request while the tls module is also loaded. After analysis it looks like a conflict between the tls module's OpenSSL memory allocator override and libcurl sharing the same OpenSSL library. I would like to report it and get the developers' opinion *Environment* - kamailio 5.8.8 (x86_64/linux), AlmaLinux 9.6, sofware recompiled from source. - OpenSSL 3.5.1 - libcurl 7.76.1, OpenSSL backend - http_client.so and tls.so are linked against the SAME libcrypto.so.3 - Multi-process (default forking model), tls used for WSS listeners *Call scenario* Call to a registed UA. When the call is being process, the kamailio script (kamailio.cfg) uses http_client_query to POST to Amazon SNS (Simple Notification Service) to handle push notifications. When the call is being process, kamailio crashes when the http_client_query function is called. *This is happening for every single call*. I did make sure that tls.so is loaded BEFORE http_client.so as per the doc. *Analysis* Here is the core stack trace: == Backtrace (trimmed) == #0 ossl_asn1_primitive_free (pval=..., it=0x0, embed=0) at crypto/asn1/tasn_fre.c:174 #1 ossl_asn1_primitive_free (...) at crypto/asn1/tasn_fre.c:203 #2 ossl_asn1_template_free (...) at crypto/asn1/tasn_fre.c:146 #3 ossl_asn1_item_embed_free (...) at crypto/asn1/tasn_fre.c:114 #4 ASN1_item_free (...) at crypto/asn1/tasn_fre.c:20 #5 x509_pubkey_ex_free (...) at crypto/x509/x_pubkey.c:91 ... #27 PEM_X509_INFO_read_bio_ex (...) at crypto/pem/pem_info.c:168 #28 X509_load_cert_crl_file_ex (...) at crypto/x509/by_file.c:250 #31 X509_STORE_load_file_ex (..., file="/etc/pki/tls/certs/ca-bundle.crt", ...) at crypto/x509/x509_d2.c:57 #32 SSL_CTX_load_verify_file (..., CAfile="/etc/pki/tls/certs/ca-bundle.crt") at ssl/ssl_lib.c:5613 #33 ossl_connect_step1 (...) at ../../lib/vtls/openssl.c:3043 #34 ossl_connect_common (...) at ../../lib/vtls/openssl.c:4045 #35 Curl_ssl_connect_nonblocking (...) at ../../lib/vtls/vtls.c:370 #37 Curl_http_connect (...) at ../../lib/http.c:1519 #40 multi_runsingle (...) at ../../lib/multi.c:1847 #41 curl_multi_perform (...) at ../../lib/multi.c:2403 #44 curl_easy_perform (data=...) at ../../lib/easy.c:715 #45 curL_request_url (..., _url="https://.../notifications/event", ...) at functions.c:298 #46 http_client_request_c (...) at functions.c:720 #48 http_client_query (...) at functions.c:744 #50 w_http_query_script (...) at http_client.c:1007 #51 w_http_query_post (...) at http_client.c:1024 #52 do_action () ... *Claude point of view on the issue* Because http_client uses libcurl, which uses the very same OpenSSL, libcurl's TLS allocations also go into Kamailio shared memory. OpenSSL 3.x keeps process -global state (OSSL_LIB_CTX, providers, the OSSL_DECODER method cache, algorithm fetch caches). When libcurl triggers the ASN.1 decode of the CA bundle, OpenSSL writes into those global caches - which now live in SHM and are shared by every worker process - while the pointers referencing them are in each process's private (COW) memory. OpenSSL's internal mutexes are process-local, so multiple workers end up reading/writing the same SHM OpenSSL structures concurrently without effective cross-process locking, corrupting the SHM heap. The crash then surfaces in the ASN.1 decoder (corrupted item, it=NULL). *Related issues / pull requests :* * https://github.com/kamailio/kamailio/pull/4640 - removal of SHM and pthreads shims in multi-threaded mode * https://github.com/kamailio/kamailio/issues/2912 My questions: * Should we migrate to 6.1 or backport the PR 4640? * Could it be caused by the fact that libssh is autoinitializing itself when the .so is loaded ? * Has someone run into this? Thanks in advance, Emmanuel

3 7

Which nat_uac_test() flags should be used for accurate NAT detection in onreply_route?
by xf han 01 Jun '26

01 Jun '26

Hello, I would like to ask about the best practice for NAT detection in Kamailio, especially in `onreply_route`. In `request_route`, I usually use the following combination: nat_uac_test("18") which means `2 + 16`: - `2`: compare the address in the top Via header with the source IP address of the SIP message. If the Via header does not contain a port, the default SIP port 5060 is used. - `16`: test whether the source port is different from the port in the Via header. If the Via header does not contain a port, the default SIP port 5060 is used. This is similar to the `aggressive-nat-detection` option in a FreeSWITCH SIP profile, which also checks the Via header. I also understand that flag `64` can be used to detect whether the source connection is WebSocket, and that is fine. However, I am not sure what the correct approach is in `onreply_route`. For SIP replies, should I still use `nat_uac_test("18")`, or are flags `2` and `16` not reliable in `onreply_route` because the Via header and source address/port have a different meaning for replies? Which `nat_uac_test()` flags are recommended in `onreply_route` for accurate NAT detection? For example, should I use a different combination, such as checking the Contact header or SDP instead of Via-based tests? Any guidance or example configuration would be appreciated. Thank you.

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users June 2026